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This  report  deals  with  a  survey  of  the  data  required  as  input  to  the 
primary  AMIP  models  (the  Force  Evaluation  Model  (FORCEM),  a  theater  force 
model  used  by  the  Concepts  Analysis  Agency  (CAA);  the  Corps  and  Division 
Evaluation  Model  (CORDIVEM),  a  corps  and  division  model  used  by  the 
Combined  Arms  Combat  Development  Activity  (CACDA);  and  the  Combined  Arms 
and  Support  Task  Force  Evaluation  Model  (CASTFOREM),  a  combined  arms  task 
force  model  used  by  the  TRADOC  Systems  Analysis  Activity  (TRASANA))  and 
with  a  survey  of  commercially  available  Data  Base  Managaement  Systems 
(DBMSs)  which  are  candidates  for  managing  these  data. 

1.1.1  AMIP  Model  Data  Base  Requirements 

In  each  case  it  was  found  that  agency  study  directors  assemble  input 
information  specifically  for  each  study  and  then  create  data  bases  for  the 
models  to  be  used.  The  distinction  between  study  requirements  and  model 
requirements  is  subtle  but  important  in  its  impact  upon  data  base 
requirements.  The  maximum  data  base  requirement  for  the  three  major  AMIP 
models  approximates  430  megabytes  with  all  data  items  being  unique  to  one, 
nti  only  one,  model.  Such  uniqueness  is  due  to  differences  in  dcsign’^tion 
of  units,  location  of  units  and  battlefield  features,  differences  in 
levels  of  resolution,  and  some  conflicting  definitions  among  the  models. 
Existence  of  such  differences  is  not  surprising  in  view  of  the  absence  of 
an  overall  model  development  philosophy  and  policy. 

1.1.2  Data  Base  Management  Systems 


Eight  commercial  DBMSs  and  a  data  base  machine  were  evaluated  to  identify 
the  candidate  that  best  meets  AMIP  data  base  management  needs.  Five  of 


the  DBMSs  are  compatible  with  the  Univac  1100/80/82  in  residence  at  the 
three  agencies,  one  with  PDP-11  and  VAX-11,  one  with  IBM,  and  one  with 
Honeywell  computers.  The  data  base  machine  is  being  configured  for  use 
with  Univac  1100  computers.  In  every  case  it  was  determined  that 
functional  capabilities  associated  with  control  and  management  of 
characteristics  and  contents  of  the  data  base  were  of  more  importance  than 
performance  efficiency  and  capacity.  All  of  the  candidates  surveyed  have 
adequate  capacity  and  none  of  the  agencies  is,  at  present,  taxing  the  CPU 
capacity  of  the  Univac  1100.  Because  of  this,  selection  of  a  DBMS  can  be 
made  on  the  basis  of  the  best  combination  of  management  and  control 
features  offered  by  the  candidates.  This  is  highly  to  be  desired  due  to 
the  numerous  sources  of  data,  the  varying  formats  and  subsets  of  data 
required  by  the  models,  and  the  numerous  versions  of  the  data  required  by 
the  users  of  the  models.  It  also  is  compatible  with  the  stated  Army  goal 
of  implementing  a  standard  data  format  so  that  all  users  may  extract  their 
data  needs  from  a  well-established  repository  having  known 
characteristics.  Control  of  format,  control  of  access  for  read,  use,  or 
update,  and  accountability  for  validity  of  contents  are  included  features. 

1.1.3  Selection  Criteria 

Evaluation  criteria  were  developed  from  definitions  of  desired  DBMS 
functions  and  their  relative  importance  to  AMIP  needs.  The  resulting 
array  is  shown  in  the  first  table  of  the  Evaluation  Scores  (paragraph 
3.2.3).  The  other  criterion  for  selection  was  total  cost  of 
implementation. 

1.1.^  Recommendations 

It  is  recommended,  with  certain  reservations,  that  the  Univac  DMS-1100  be 
adopted  as  the  AMIP  DBMS.  Reservations  concern  the  difficulty  of  data 
base  design  in  the  CODASYL  data  model  resident  in  DMS-1100.  The  degree  to 
which  such  difficulty  poses  a  real,  rather  than  a  perceived,  problem 
requires  definition. 


Arms  and  support  models,  together  with  automated  war  games,  form  the  basis 
for  Army  analytical  studies  of  complex  force  interactions  in  battleiield 
environments.  These  models  have  been  developed  in  response  to  the 
requirements  of  specific  agencies  or  specific  study  applications. 
Consequently,  there  has  been  little  systematic  development,  documentation, 
consistency,  validation,  or  long-term  direction.  Existing  Army  models 
tend  to  be  complex  and  sophisticated,  focusing  on  weapons  characteristics 
and  performance,  rather  than  on  such  battlefield  functions  as  logistics, 
casualty  estimation,  force  reconstitution,  command,  control,  communication 
and  intelligence  electronic  warfare  (E^)  and  engineer  support. 

A  review  of  Army  analysis  was  begun  in  1978  with  the  objective  of 
evaluating  Army  analysis  capabilities  and  proposing  improvements. 
Pecommendations  included  development  and  implementation  of  a  family  of 
structured  combat  and  support  models  with  an  integrated  data  base.  The 
program  which  grew  out  of  these  recommendations  was  named  the  Army  Model 
Improvement  Program  (AMIP).  Subsequently ,  an  AMIP  Management  Office 
(AMMO)  was  established  at  Ft.  Leavenworth,  KS. 

Under  this  program,  three  versions  of  the  models  are  to  be  developed: 

o  Automated  combat  and  support  simulations. 

o  Interactive,  man-in-the-loop,  computer-assisted  war  games. 

o  Training  games  run  manually  or  without  computer  support. 

Automated  simulations  are  to  be  employed  when  a  rapid  response  to  Army 
study  requirements  is  required.  Interactive  war  games  are  used  to  gain 
insights  into  combat  processes  and  force  structures,  to  evaluate  potential 
new  weapon  systems,  to  interface  with  the  simulations,  and  ultimately  to 


interface  with  the  training  games.  Training  requirements  will  dictate  the 
need  for  and  character  of  the  training  versions. 

Although  weapons  performance  remains  important,  processes  and  activities 
incident  to  a  weapon* s  firing  will  be  featured  in  the  modeling,  which  will 
include  all  levels  of  operations  and  their  supporting  functions  and 
services.  The  hierarchy  of  combined  arms  and  support  simulation  models  is 
seen  as  an  integrated  family  of  analytical  tools  with  three  major 
components:  FORCEM,  CORDIVEM,  and  CASTFOREM. 

1.2.1  FORCEM 

The  FORCEM  component  will  address  the  issues  of  alternatives  for  improved 
force  readiness,  design  of  theater  force  structure,  and  determination  of 
theater  resources  required  for  sustained  combat  operations.  ^FORCEM 
development  will  take  the  shape  of  a  series  of  modular  steps  in  making  a 
planned  transition  from  the  current  theater  model,  CEM-V,  to  the  FORCEM 
model.  As  CEM  modules  are  replaced  or  new  modules  are  added,  the  model 
will  gradually  change  in  structure  and  operation  while  constantly 
remaining  available  for  CAA  studies.  The  effects  of  the  modular  changes 
can  thus  be  examined  in  a  stepwise  fashion  as  the  program  develops  an  end 
product  bearing  little  resemblance  to  CEM.  The  areas  to  be  improved 
include  C2,  intelligence,  communications,  maneuver/ v'  ' '  otronic 
warfare,  combat  support,  combat  service  support,  air  operations,  and 
environment. 

1.2. 1.1  CEM 

The  Concept  Evaluation  Models  (CEM)  are  theater  simulations  of 
conventional  war  which  have  evolved  from  Kriegspiel,  the  manual  wargame 
developed  for  the  German  General  Staff  In  the  1930s  (see  Figure  1-1).  In 
CEM-V  the  battle  area  Is  divided  Into  corps  sectors  with  sub-sectors  for 
brigades  on  the  Blue  side  and  divisions  on  the  Red  side.  Attrition  is 
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calculated  by  the  use  of  a  force  ratio  index  number  that  involves  f 
Evaluation  Indi ees/Wcighted  Unit  Values  (KKl/WUV)  scores.  Tt-:  r 
treated  in  aggregated  bands  across  sub-sectors.  Supplies  are  ex;  j  : 1 1  y 
treated.  Penetrations  can  be  treated  to  a  limited  degree  with  aliocation 
of  forces  to  flanks.  The  maximum  number  of  types  of  units  is  50.  The 
force  being  simulated  can  contain  up  to  eight  different  types  of  cannon. 
Direct  support  artillery  is  assigned  to  brigades/regiments.  Time  periods 
are:  corps,  one  day;  army,  two  days;  theater,  four  days.  Shortage  of 

supplies  can  affect  outcomes.  There  are  two  notional  aircraft  types  per 
side.  There  is  an  explicit  command  structure  with  decisions  made 
according  to  decision  rules  based  on  force  ratios  and  unit  status.  Three 
postures  are  available  to  units;  attack,  defend,  delay.  Modificatir  ns  of 
the  model  have  been  developed  for  study  of  reinforcements,  supplies,  and 
casualties  (WARAMP) . 

1.2. 1.2  Data  Base 

Data  base  development  for  the  FORCEM  model  falls  into  at  least  four  areas 
as  outlined  below: 

o  Force  Data.  Work  has  begun  on  development  of  an  automated 

management  system  for  theater  force  data  drawing  from  standard 
Army  sources  such  as  TOE  and  the  Fcrce  Accounting  fyst(  . 

o  Environment  Data.  Demographic  data  (population,  terrain, 
average  weather,  climate)  will  be  drawn  from  standard 
references,  as  they  are  essentially  stable  and  require  less 
elaborate  data  management  provisions.  Other  environmental  cita, 
such  as  local  weather  and  battlefield  obscuration,  will  be 
volatile,  will  be  supplied  by  lower  level  models,  and  will 
require  more  elaborate  data  management  provisions. 
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Performance  Data.  The  theater  model  will  not  normally  portray 
individual  systems  explicitly.  Most  performance  data  will  be 
received  from  higher  resolution  models  or  functional  area 
models  as  calibration  data.  Procedures  for  Identifying, 
storing,  and  retrieving  desired  data  must  be  developed. 

o  Situation  Data.  Data  for  specification  of  theater  force 

organization  and  concept  of  operation  must  be  developed  to 
include  incorporation  of  decision  logic  and  command  policies 
that  could  affect  the  outcome.  Again,  situation  reports  from 
higher  resolution  models  will  be  an  important  part  of  the 
situation  data  input  for  FORCEM. 

1.2.2  CORDIVEM 

The  CORDIVEM  Model  will  be  corps  level  in  scope  with  the  capability  of 
simulating  a  division  or  a  corps.  Its  primary  use  will  be  to  supply 
information  for  design  and  force  structure  trade-off  analyses  of  Army 
organizations  such  as  brigades,  divisions,  and  corps.  A  secondary  use 
will  be  in  support  of  studies  of  systems  normally  organic  to  major 
organizations.  CACDA  is  developing  the  CORDIVEM  Model  by  making  a 
composite  model  from  desirable  elements  of  the  ICOR  Model  and  other  models 
resident  at  CACDA. 

1.2. 2.1  ICQR 


The  TCOR  simulations  (CLEW  II,  ICOR,  TCOR,  WARRANT)  are  a  family  of 
simulations  of  corps  level  operations  (see  Figure  1-2).  They  have  been 
designed  to  be  applied  to  a  variety  of  analyses  including  nuclear  weapon 
use,  interdiction,  sensor  systems,  and  command  and  control.  The  battle 
area  is  laid  out  on  a  hexagonal  coordinate  system  allowing  two-dimensional 
movement  of  forces.  Penetration,  encirclement,  and  over-run  are 
explicitly  represented.  Attrition  is  calculated  by  a  modified  Lanchester 


equation  Including  suppression,  visibility,  terrain,  and  other  factors. 
The  model  is  operated  interactively  with  the  operator  (force  commander)  on 
each  side  being  presented  with  Information  from  representations  of  sensor 
systems  and  from  status  reports  on  his  own  forces.  The  ground  forces 
operate  by  the  operations  reaction  system  that  responds  to  orders  given, 
the  status  of  the  unit  postured,  and  the  situation.  The  time  interval 
(usually  five  minutes  simulated  time)  is  the  actual  calculation  time  for 
events  simulated.  Weapon  types  are  specific.  Units  move  by  operations 
codes  and  are  affected  by  terrain,  suppression,  massing,  and  perceived 
threat.  Artillery  is  represented  by  specific  location  of  batteries. 
Artillery  missions  include  target  servicing  indirect  fire  (TSIF), 
counterfire.  Interdiction,  and  suppression  of  enemy  air  defense.  Air 
support  is  represented  by  a  notional  air  base  from  which  sorties  are 
generated  by  the  operator.  Aircraft  types  include  helicopters.  Air 
defense  is  explicit.  Intelligence  sensors  are  generic  or  specific 
depending  on  the  version  of  the  simulation.  For  explicit  sensors  (IMINT, 
SIGINT,  and  maneuver  unit  acquisition  -  air  and  ground)  the  information  is 
processed  and  presented  to  the  appropriate  level  of  command.  Logistic 
support  is  explicit  for  both  conventional  and  nuclear  operations.  Command 
and  control  links  exist  from  corps  through  battalion. 

The  CACDA  terrain  model  incorporates  a  digitized  representation  of  terrain 
which  is  used  to  give  the  operator  a  realistic  visual  image  of  the  terrain 
upon  which  the  battle  is  fought. 

1.2. 2. 3  Force  Organization  Control  System  (FOCS) 

The  FOCS  is  a  system  for  managing  force  organization  data  which  includes 
15  different  types  of  TOE  and  related  data  along  with  changes  in  numbers 
and  status  of  TOE  items  as  a  result  of  simulated  combat. 
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Data  Base 


Data  base  development  includes  descriptions  of  the  battlefield 
environment,  the  forces,  and  system  and  unit  performance  factors. 

o  Surface  Description.  Surface  description  data  include 

elevation  values  of  local  surface  features,  road  and  rail  nets, 
hydrography,  and  off-road  mobility  potential*  Data  for  the 
initial  geographic  area  within  the  Federal  Republic  of  Germany 
(FRG)  were  completed  in  late  1980  and  other  areas  are  planned. 
Digitization  of  terrain  data  is  proceeding  more  slowly. 

o  Climatic  Description.  The  U.S.  Army  Atmospheric  Sciences 

Laboratory  is  developing  climatic  data  for  areas  of  interest. 

The  data  include  cloud  conditions,  visibility,  temperature, 
winds,  precipitation  and  other  climate  factors.  The  data  will 
be  organized  into  weather  regions  for  hourly  conditions  and  will 
be  available  for  Mod  II  application  in  late  1983. 

o  Force  Description.  Data  to  describe  force  composition,  unit 
composition,  echelonment,  command  relationships,  and  other 
scenario-related  information  will  be  developed  for  both  sides. 

The  data  will  define  the  force  elements  modeled  and  their 
battlefield  activities.  The  preliminary  data  structures  and 
processing  algorithms  in  the  Force  Organization  and  Control 
System  (FOGS)  developed  by  CASAA  will  be  modified  to  meet 
functional  design  requirements. 

o  System  and  Unit  Performance.  The  most  critical  item  in  the 
CORDIVEM  development  is  definition  of  scope  and  detail  of 
events,  activities,  and  processes  that  model  battlefield 
functions.  These  data  define  unit  operational  capability  and 
performance  profiles  for  battlefield  systems,  quantification  of 
tactics  and  doctrine,  and  interfaces  and  interactions  among 
modeled  units  and  systems,  and  with  the  battlefield  environment. 
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1.2.3  CA?TFP.PEM 


The  CASTFOREM  component  will  be  task  force  level  in  scope  and  will 
represent  the  detailled  combat  operations  of  the  combined  task  force  and 
its  support  to  determine  the  effectiveness  of  units  and  item  systems.  It 
will  also  record  the  approximate  level  of  personnel  and  equipment 
attrition  and  the  magnitude  of  resources  consumed  in  the  course  of  the 
task  force  operations. 

1.2. 3.1  BESS 

The  Battlefield  Engagement  Stochastic  Simulation  (BESS),  under  development 
at  TRASANA,  will  serve  as  the  basis  for  CASTFOREM  (see  Figure  1-3). 
CASTFOREM  Mod  I  (BEST)  was  demonstrated  in  October  1980,  and  the  CASTFOREM 
II  design  phase  was  completed  in  April  1 981 .  Mod  III  design 
specifications  will  expand  upon  those  of  Mod  II  and  will  include  aviation, 
engineer,  artillery,  and  combat  service  support  representation.  Specific 
depictions  are  made  of  nearly  all  battlefield  functions  (close  combat, 
fire  support,  air  defense,  combat  support,  combat  service  support, 
ccmmunications,  command  and  control,  intelligence  and  electronic  warfare) 
and  the  battlefield  environment. 

1 . 2 . 3  - 2  Base 

Data  base  development  for  CASTFOREM  was  started  in  August  1980  and  is  well 
on  the  way  to  completion.  Documentation  of  the  model  proceeds  apace  with 
model  development.  The  data  base  for  CASTFOREM  is  characterized  by 
extremely  fine  detail  on  items,  systems,  and  units  with  a  complete  audit 
trail  to  the  origin  of  each  bit  of  data. 


1.3 


The  flow  of  data  within  the  Army  modeling  agencies  is  exemplified  by 
Figure  1-^.  All  agencies  maintain  a  certain  amount  of  data  in-house  which 
is  largely  non-volatile.  External  data  sources  are  consulted  to  complete 
the  information  requirements  for  a  specific  study.  The  agencies  then 
manually  transform  the  collected  Information  into  data  for  input  to  a 
specific  model.  Such  transformation  entails  specific  formatting,  naming, 
listing,  and  dimensioning  to  meet  the  design  characteristics  of  each 
model.  This  survey  has  examined  the  contents  of  the  boxes  labeled  "Study 
Data  File",  "Study  Input  Rqmts",  and  "Model  Rqmts"  in  Figure  1-i*. 

1 Data  Base  Management 

1.^.1  Current  AMIP  Data  Base  Management  Systems 

All  three  AMIP  agencies  currently  have  Data  Base  Management  Systems  (DBMS) 
which  they  are  essentially  not  using  to  manage  AMIP  data.  CAA  has  a  DMS 
1100  and  a  MIRADS  (Figure  1-5)  which  are  used  for  administrative  and 
accounting  purposes  and  for  managing  some  study  related  data,  but  not  data 
related  to  FORCEM  (or  CEM  V).  Instead,  separate  study  data  files,  most 
with  essentially  redundant  data,  are  maintained  for  each  study  conducted. 
CASAA  shares  the  availability  of  DBMSs  with  other  organizations  at  Ft. 
Leavenworth.  As  Figure  1-6  indicates.  System  2000,  QUERY/UPD  and  DMS  1100 
are  currently  available  at  Ft.  Leavenworth  but  essentially  not  used  for 
A>1IP  type  data  management.  (Although  the  System  2000  is  used  to  support 
analyses  by  managing  and  cross-referencing  library  documents).  TRASANA 
has  a  DMS  1100  that  is  used  for  document  retrieval,  but  not  otherwise  used 
for  data  base  management. 
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Currently,  CAA,  CASAA  and  TRASANA  keep  essentially  redundant  data  "files" 
of  records  for  each  study  application.  The  intent  of  a  data  base  is  to 
allow  that  same  collection  of  data  to  serve  as  many  applications  as  is 
useful.  Hence,  a  data  base  may  be  conceived  of  as  the  repository  of 
information  needed  for  running  certain  functions  within  and  among  the  Army 
agencies.  Such  a  data  base  would  permit  not  only  the  retrieval  of  data, 
but  also  its  continuous  modification  as  needed  to  support  the  Army 
modelling  effort.  It  would  also  permit  "tagging"  each  data  item  to 
maintain  an  account  of  its  precise  origin  and  meaning  (Data  Dictionary  and 
Directory) ,  and  could  ensure  commonality  of  certain  data  among  the 
studies. 

It  is  a  much  publicized  dream  of  managers  to  have  a  centralized  agency 
data  base  in  a  large  reservoir  in  which  a  diversity  of  data  users  can  go 
fishing.  Such  a  data  base  may  be  highly  complex,  and  in  general  the  dream 
may  be  far  from  being  achieved  in  reality;  but  it  should  remain  a  worthy 
goal  of  data  processing  in  the  future.  A  complex  data  base  has  to  be 
built  up  stage  by  stage.  In  reality  today  most  data  bases  serve  a  varied, 
but  limited,  set  of  applications. 

A  major  task  for  the  Army  during  this  decade  is  to  decide  what  data  b^ses 
it  needs,  where  they  are  best  located,  what  data  should  be  stored  in  them, 
and  how  they  should  be  organized.  Beginning  with  the  Hardison  Report,  and 
continuing  efforts  such  as  this  survey,  the  Army  Model  Improvement  Program 
is  beginning  to  address  its  part  of  this  major  Army  task. 


2.0  AMIf  MODEL  DATA  BASE  REQUIREMENTS 


2.1  Overall  Volume  of  Data  Required  for  AMI?_ Models 

2.1.1  CASTFOREM 

Although  data  requirements  for  CASTFOREM  are  heavily  scenario  and  user 
requirements  dependent  (more  so  than  the  other  two  AMIP  models),  the  total 
data  base  will  probably  be  12  to  13  megabytes  (mb),  Including  all  the 
program  codes  and  environmental  data,  as  well  as  the  input  data.  This 
model  differs  from  the  other  two  AMIP  models  in  terms  of  data  requirements 
because  much  of  its  input  data  will  be  provided  by  the  user  of  the 
resulting  study,  or  will  be  generated  internally  by  TRASANA  (based  on 
previous  studies),  for  approval  by  the  user.  Examples  include;  the 
Decision  Tables,  Combat  Orders,  Primitive  Orders,  CSS  and  Engineer 
Techniques,  the  search  doctrine,  and  much  of  the  Type  Unit  input  data.  Of 
the  remaining  input  data,  it  is  estimated  that  only  approximately  ten 
percent  will  require  update  from  outside  agencies  such  as  AMSAA.  TRASANA 
has  a  large  terrain  data  base  covering  approximately  63»000  KM^  on  tapes. 
Each  tape  contains  terrain  data  for  a  typical  CASTFOREM  analysis 
(approximately  20  x  20  KM).  At  the  terrain  resolution  required  by 
CASTFOREM,  9600  bytes  are  required  per  square  KM,  or  about  four  megabytes 
per  battalion  task  force  study. 

2.1.2  CORDIVEM 

Because  CORDIVEM  will  be  an  interactive  model,  a  large  portion  of  its 
input  data  will  be  provided  by  the  players  during  the  analysis.  The 
current  baseline  configuration  will  require  about  ten  mb,  but  the 
production  model  is  expected  to  consist  of  over  M16  mb.  Most  of  this  data 
(336  mb)  will  be  required  for  game  history  in  support  of  the  player 
interface.  Of  the  80  mb  remaining,  digitized  terrain  consumes  most  (72 
mb).  The  72  mb  will  probably  not  be  on  line.  This  is  only  the  European 
Terrain  and  it  does  not  include  the  lines  of  coramunication/hydrography, 
nor  the  HEX  data  bases,  that  are  presently  in  the  ICOR  data  base.  The  HEX 
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data  base  will  be  expanded  both  In  size  and  to  other  geographical  ar*  'i.*  . 
P'igure  2-1  depicts  the  relative  volume  of  data  that  is  forecast  .  ..c 
in  each  of  the  AMIP  model  data  bases.  From  the  chart  It  is  clt.ar  tr.at 
COllDIVEM  will  have  the  largest  data  base  (excluding  the  large  accu::.c j  ation 
of  terrain  data  at  TRASANA).  The  Red/Blue  forces  data  base  and  the  ICOR 
Core  resident  static  and  dynamic  data  base  constitute  about  one  megabyte 
each.  Weapon  ef feet i veness  data  (planned  as  input  from  CASTFOREK)  are 
expected  to  consume  less  than  ^00  kilobytes.  Updating  of  the  C0RDIVE!<  cata 
base  will  probably  consist  of  about  10  percent  of  the  Red/Blue  Force 
Organization  (about  102  kilobytes)  and  probably  all  the  inputs  from 
CASTFOREM  (390  kilobytes).  These  constitute  an  estimated  total  update 
requirement  of  about  one-half  a  megabyte  each  time  a  major  study  is 
initiated  using  CORDIVEM. 

2.1.3  FORCEM 

FORCEM  will  likely  have  the  smallest  data  base  of  the  three  AMIP  models 
(about  365  kilobytes),  but  require  the  largest  input  data  updates.  This 
is  because  the  theater  model  is  sensitive  to  a  broader  range  of  variables. 

It  is  used  to  assess  changes  in  fiscal  appropriations  (and  therefore  is 
sensitive  to  the  POM  Cycle),  as  well  as  changes  in  employment  doctrine 
(reflecting  a  sensitivity  to  TRADOC  doctrinal  force  inputs),  and  changes 
in  Red/Blue  performance  results  (i.e.,  Killer/Victim  Scoreboards ) . 
Currently,  the  CAA  data  base  which  will  later  be  reflected  in  FORCEM  has  a 
minor  update  every  two-to-four  months  when  a  new  major  study  is  initiated, 
and  a  major  update  annually  when  the  new  outyear  force  of  the  FYDP  is 
defined. 

2.1.4  Conclusion 

The  maximum  data  base  requirements  for  all  the  AMIP  models  is  expected  to 
be  about  430  megabytes  ...  assuming  that  no  data  are  duplicated  in  more 
than  one  model.  Because  all  commercial  DBMSs  under  consideration  have  a 
data  base  handling  capacity  in  the  billions  of  bytes  (for  example, 
ADABAS-M  has  a  maximum  capacity  of  8x10^^*  bytes),  it  can  be  concluded 


y 
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ive  Size  of  A>UP  Data  Bases 


that  the  volume  of  AMIP  data  is  not  a  serious  consideration  for  ' i 

of  a  DBMS.  Any  of  the  considered  DBMSs  could  accommooate  the  tot..  . 

base  of  any  of  the  AMIP  modelf.,  or  of  all  their  corat  ined  u.j  •  ,  ;lf. 

adequate  capability  remaining  to  accomodate  AMIP  model  exparn:*  .  or 
addition  of  other  model  data  bases  to  the  AMIP  program, 

•Assuming  all  limits  can  be  approached  independently.  A  safer  estimate 
would  be  3-Sx10^,  still  well  above  AMIP  requirements, 

2 . 2  Force  Description  Representation 

2.2.1  General 

Each  of  the  three  models  represents  the  Red  and  Blue  forces  in  its  own 
unique  way  Although  some  "candidates"  for  commonality  were  identified, 
no  common  data  items  will  exist  among  the  models  under  the  current  plans 
for  development. 

2.2.2  Unit  Locations 

The  method  of  accounting  for  unit  locations  differs  in  all  the  models  (see 
Figure  2-2) ,  but  all  use  the  UTM  coordinate  system.  CASTFOREM  uses  UTM  to 
identify  the  unit’s  Command  Post  location  (a  point),  while  FORCEM  ust  '  UTM 
to  identify  the  portion  of  the  FEBA  occupied  by  the  unit  (a  line). 
CORDIVEM  uses  UTM  to  develop  its  HEX  address  system.  Opportunities  for 
duplicating  data  in  more  than  one  model  occur  at  battalion,  company  and 
platoon  levels  for  CORDIVEM  and  CASTFORFM,  and  at  corps,  division  and 
brigade  levels  for  FORCEM  and  CORDIVEM,  as  shown  in  the  figure.  No 
candidate  exists  for  three-way  overlap, 

2.2.3  Unit  Designations 


The  AMIP  models  have  three  separate  schemes  for  unit  designation  (Figure 
2-3).  FORCEM  uses  an  eight  character  unformatted  TEXT  variable  for 
designating  corps,  divisions  and  brigades  (e.g.;  2  ARM).  CORDIVEM  uses  an 
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eight  character  FOR>tATTED  numbering  system  (e.g.;  SDDRRBBB).  CACTr(jKt:!: 
uses  18  unfc'naatted  text  characters  to  designate  its  units.  As  Figu,  ^-3 
indicates,  no  three-way  overlap  exists  in  unit  designations,  tu .  :i.it 
levels  could  be  duplicated  in  two  models.  Brigade  through  ccr; :  are 
common  to  FORCEM  and  CORDIVEM  and  platoon  through  battalion  are  coinmcn  for 
CASTFOREM  and  CORDIVEM.  Through  reformatting  of  the  unit  designations,  it 
may  be  possible  for  a  common  link  to  be  established  from  CASTFOREM  to 
CORDIVEM,  and  from  CORDIVEM  to  FORCEM  ...  establishing  a  foundation  for 
passage  of  force  description,  performance  or  characteristics  information 
from  model  to  model,  should  that  be  desired. 


2.2.4 


All  three  AMIP  models  will  account  for  force  composition  and  structure  by 
identifying  subordinate  units  (shown  as  "ID  Sub"  in  Figure  2-4)  assigned 
to  each  headquarters.  CORDIVEM  and  CASTFOREM  also  account  for  superior 
(or  owner)  of  each  unit.  CORDIVEM  also  identifies  the  type  of  unit  from 


em  Types 


most  units  and  systems*  CASTFOREM  is  designed  to  accomodate  as  many 
variations  from  standard  units/systems  as  the  user  chooses  to  identify* 

2*3  lagtAgai  A^.rsr.aft..  and.  AJLrJ^ejLs^  Bepr^ejiutlgn 

TACAIR  and  ground  based  air  defense  forces  are  treated  differently  in  each 
of  the  three  models.  Because  of  CASTFOREM' s  small  geographical  area  of 
consideration,  only  Close  Air  Support  (CAS)  and  Short  Range  Air  Defense 
(SHORAD)  forces  are  gamed,  and  those  only  in  the  vicinity  of  the  evaluated 
force  (e.g.;  Battalion  Task  Force).  Figure  2-7  illustrates  the  process 
used  by  CASTFOREM  to  game  SHORAD*  CORDIVEM  can  explicitly  or  implicitly 
play  air  defenses  (although  it  always  explicitly  plays  TACAIR)*  When 
explicit,  both  SHORAD  and  longer  range  air  defenses  (I-HAWK  and  PATRIOT, 
for  example)  are  played  against  the  total  TACAIR  force.  Aircraft  sortie 
flight  paths  are  represented  from  the  airfield  to  the  target  and  back  (HEX 
identification),  and  air  defense  weapons  are  gamed  against  them*  FORCEM 
also  assesses  the  total  theater  TACAIR  force  against  the  total  air  defense 
force,  but  it  employs  an  attrition/service  rate  approach;  reducing  the 
number  of  aircraft  in  the  force  based  on  the  rate  of  attrition  and  the 
duration  of  exposure  to  the  attrition*  Air  defense  systems  are  assessed 
based  on  tons  of  ammunition  expended  per  aircraft  kill. 

While  the  CASTFOREM  data  base  offers  little  opportunity  either  for 
commonality  of  data  with  the  other  models,  or  calibration  of  CAS  or  air 
defense  for  them,  there  do  appear  to  be  opportunities  for  commonality 
between  CORDIVEM  and  FORCEM.  Generally,  both  assess  the  total  theater 
force  of  US  TACAIR  and  ground  based  air  defenses.  Because  CORDIVEM  games 
them  and  FORCEM  does  not,  there  might  be  future  opportunities  for  CORDIVEM 
to  calibrate  FORCEM  TACAIR  and  air  defense  forces  with  killer/victim 
scoreboards*  Conversely,  aircraft  and  air  defense  logistics  and 
maintenance  results  obtained  in  FORCEM  may  be  of  value  in  calibrating  the 
availability  of  these  assets  In  CORDIVEM* 
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One  dimension  that  should  be  discussed  is  the  representation  of  allies  in 
the  AMIR  models.  CASTFOREM  does  not  normally  include  allies  in  :l 
base  because  it  exists  principally  to  game  US  Battalion  Tasr.  force 
equipment,  doctrine  and  tactics  (although  it  could  game  alllec  forces  If 
required).  Because,  like  CASTFOREM,  CORDIVEM  will  be  oriented  toward 
assessing  US  division  and  corps  doctrinal  considerations,  it  will  probably 
not  maintain  a  data  base  consisting  of  non-US  Blue  Forces.  FORCEM,  on  the 
other  hand,  will  maintain  an  extensive  base  of  allied  forces  data.  This 
difference  in  FORCEM  and  CORDIVEM/CASTFOREM  data  requirements  does  not 
appear  to  be  a  potential  obstacle  to  centralizing  a  data  base,  and,  In 
fact,  could  offer  opportunities  for  CORDIVEM  assessments.  If  a  common 
data  base  existed  which  could  facilitate  feeding  an  allied  force  data  base 
into  a  CORDIVEM  model,  the  US  forces  performance  could  be  assessed  in  a 
broader  theater-wide  context.  (For  example,  assessment  of  a  V  Corps 
response  to  a  large  scale  penetration  in  a  non-US  corps  on  its  flank). 

2.5  Doctrinal  vs.  Fiscally  Constrained  Forces 

TRASANA  and  CASAA,  being  agencies  within  TRADOC,  are  principally 
interested  in  providing  assessments  of  doctrinal  forces  and  their  optimal 
employment  (Division  86  forces,  for  example).  CAA,  on  the  other  hand, 
will  probably  have  a  different  force  in  its  data  base  ...  a  force  that  is 
fiscally  constrained  within  the  Five  Year  Force  Development  Plan  (FYDP) 
projections.  The  data  base  representing  the  1986  division  gamed  by  FORCEM 
in  support  of  the  DA,  DCSOPS  Staff  may  bear  little  resemblance  to  the  1986 
division  gamed  by  CORDIVEM  or  the  battalion  task  force  gamed  by  CASTFOREM 
in  support  of  TRADOC. 

The  passage  of  performance  results  such  as  Killer/Victim  Scoreboards  from 
CORDIVEM,  a  model  normally  used  with  doctrinal  forces,  may  not  adequately 
represent  a  fiscally  constrained  force  unless  a  constrained  data  base  is 
used.  Calibration  from  one  model  to  another  should,  therefore,  take  this 
data  base  difference  into  account. 
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^  ^  Representation 

All  three  models  use  Input  performance  data  from  AMSAA  to  determine  weapon 
system  capabilities*  Beyond  that,  however,  the  data  representation  of 
performance  data  in  CASTFOREM  is  quite  different  from  the  other  two 
models*  Variations  in  armament  composition,  muzzle  velocity,  and  aspect 
angle  of  the  target  in  relationship  to  the  weapon  system  are  variations 
from  standard  data  that  are  treated  in  CASTFOREM,  but  not  in  FORCEM  or 
CORDIVEM  (see  Figure  2-8).  The  latter  two  models  essentially  limit  their 
data  base  to  basic  data  such  as  kill  probabilities  and  average  ranges  to 
the  targets.  Analysis  has  shown  considerable  difference  in  CASTFOREM 
resolution  in  this  area  and  the  resolution  in  the  other  two  models  as 
illustrated  in  Figure  2-9.  Accordingly,  pursuit  of  a  scheme  for 
calibrating  the  weapon  system  performances  in  CORDIVEM  and  FORCEM  with 
CASTFOREM  would  appear  to  be  desirable*  The  only  performance  interface 
among  the  AMIP  models  that  is  currently  operational  is  from  CASTFOREM  to 
CORDIVEM,  using  an  analytic  model,  COMANEW,  to  resolve  combat  interactions 
in  CORDIVEM.  CEM  V,  the  current  theater  level  forerunner  to  FORCEM  is 
calibrated  by  a  stochastic  simulation  of  division  level  combat,  COSAGE. 

Kil ler/Victim  scoreboards  are  not  the  only  performance  activities  of 
importance  that  should  be  considered  for  calibration  from  one  AMIP  model 
to  another.  Candidates  include  Combat  Service  Support  (maintenance  and 
logistics),  TACAIR,  Air  Defense  and  others.  Figure  2-10  illustrates  the 
interfaces  of  requirements  and  results  which  could  exist  between  the  AMIP 
models* 

2.7  Environmental  Data  Representation 


The  environmental  data  (terrain  and  weather)  in  both  CASTFOREM  and 
CORDIVEM  models  will  be  used  to  cause  the  movement  and  interactions 
between  the  model  entities  to  reasonably  approximate  the  activity  of  real 
units  over  the  gaming  area,  and  to  the  resolution  required  by  the 
analysis.  FORCEM  also  considers  terrain,  but  not  weather*  It  is  planned 
that  if  weather  influences  unit/weapon  performance,  it  will  be  included  in 
the  calibration  provided  by  CORDIVEM  to  FORCEM.  Figures  2-11  and  2-12 
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Terrain  Data  Representation 


illustrate  the  differences  in  AMIP  model  requirements  for  environmental 
data. 

Environmental  (or  more  precisely  terrain)  data  consumes  a  significant 
portion  of  the  AMIP  model  storage  capacity  as  shown  in  Figure  2-13.  The 
CASTFOREM  model*s  terrain  data  base  covers  over  41,000  square  KM,  and  each 
square  KM  requires  9600  bytes  of  data  (or  3*84  kilobytes  per  20  x  20  KM 
area  used  for  a  battalion  task'  force  analysis).  For  comparison, 
CORDIVEM's  current  baseline  European  terrain  data  base  covers  30,000 
square  KM  and  requires  200  bytes  of  data  per  square  KM.  Within  the 
CORDIVEM  model,  terrain  storage  constitutes  97  percent  of  the  model's  data 
requirements. 

There  are  a  number  of  data  elements  common  to  more  than  one  of  the  AMIP 
models  but  the  differences  in  format  mitigate  against  standardization  of 
the  terrain  data  bases,  with  the  possible  exception  that  CORDIVEM  and 
FORCEM  require  essentially  the  same  scale  of  terrain  data  (e.g.,  the  NATO 
theater)  and  the  resolution  required  for  CORDIVEM  may  be  of  value  to 
FORCEM  in  assessing  convoy  movements  and  other  terrain  related  activities. 
Since  neither  CORDIVEM  nor  FORCEM  has  been  fully  developed,  consideration 
should  be  given  to  enhancement  of  commonalities  in  the  terrain 
representation  for  these  two  models. 
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3.0  DBMS  5 


This  section  presents  the  results  of  the  Sui'vey  and  Evaluation  o: 
ccmmerclally  available  Dato.  Rase  Management  Systems  selected  as  car  i5d 
to  provide  overall  data  management  of  Army  models  data  under  the  Army 
Model  Improvement  Program. 

Subsection  3*1  discusses  the  Survey  procedures  and  presents  the  results. 

Subsection  3.2  discusses  the  Evaluation  metholology  and  presents  results 
of  the  Evaluation,  including  scoring  results,  rationale,  conclusions  and 
recommendations. 

3.1  DBMS  Survey 

"General  Survey  of  Data  Base  Management  Systems"  has  been  prepared  for  the 
Army  Model  Management  Office  under  the  Army  Model  Improvement  Program 
contract  number  DABT58-81-C-01^7  as  a  standalone  document. 

This  survey  includes  the  five  products  which  are  considered  to  be  Data 
Base  Management  Systeifts  (DBMS)  and  which  can  be  used  on  the  UNIVAC  Series 
1100/80,  the  computer  readily  available  for  use  in  the  FORCEM,  CORDIVEM 
and  CASTFOREM  modeling  functions.  These  candidate  DBMSs  are  BASIS, 
DMS-1100,  RAPPORT,  SIBAS,  and  SYSTEM  2000.  The  sixth,  seventh  and  eighth 
candidates  are  ADABAS-M  for  PDP-11  and  VAX-11  computers,  SQL/DS  for  IBM, 
and  MRDS/Multics  for  Honeywell  computers.  The  IBM  product  is  scheduled 
for  first  delivery  during  the  first  quarter  of  1982.  It  is  a  commercial 
product  based  upon  the  research  project  "System  R".  Documentation  on 
SQL/DS  is  preliminary  and  subject  to  change.  No  user  experience  will  be 
available  for  surveying  within  the  near  future. 
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A  ninth  candidate,  a  Data  Base  Machine,  the  Britton-Lee  IDM-500,  is  being 
configured  to  be  used  with  the  UNIVAC  Series  1100  computers.  Many  of  the 
survey  questions  are  not  meaningful  for  the  data  base  machine  and  others 
are  answered  based  upon  the  potential  of  the  IDM-500,  not  on  proven  or 
documented  capabilities.  Within  this  report  the  term  "DBMS"  generally 
will  include  all  nine  candidates  without  implying  that  each  candidate 
strictly  conforms  to  the  definition  of  a  DBMS. 

3.1.1  Survey  Methodoloity 

The  survey  presents  major  categories  identifying  desired  DBMS  funtions  and 
general  information  concerning  the  implementation  of  each  DBMS.  Each 
major  category  has  been  defined  in  further  detail  where  necessary,  in 
terms  of  sub-functions  and/or  components,  so  that  the  bulk  of  the  survey 
could  be  completed  by  indicating  whether  or  not  each  DBMS  supports  the 
specific  feature.  For  the  most  part,  this  survey  does  not  try  to  answer 
subjective  or  performance  related  questions  such  as  the  "ease  of  .  •  ."or 
the  "speed  of  .  .  .".  It  notes  simply  that  the  function  can  be  done  or 
cannot  be  done  in  the  case  of  unambiguously  specified  capabilities,  or  to 
what  degree  of  completeness  or  power  it  has  been  implemented  in  other 
cases.  A  blank  entry  indicates  that  insufficient  documentation  was 
available  on  the  subject.  Features  that  required  more  information  have 
been  accompanied  by  a  reference  to  the  Explanatory  Notes  pages.  All 
information  in  support  of  this  survey  has  been  obtained  from  vendor 
documentation,  reports  of  previous  performance  evaluations,  and  other 
technical  literature,  as  listed  by  code  on  the  Bibliography  pages.  The 
source  of  information  for  each  category  of  the  survey  has  been 
cross-referenced  through  Source  Citations  pages  the  form  bibliography- 
code:  page-number.  Obviously  the  accuracy  is  limited  to  the  accuracy  of 
the  source  data. 
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3. 1.1.1 


Sources  used  are  of  the  following  kind: 

o  Vendor  documentation  currently  resident  in  the  Mc2 
technical  library 

o  Additional  documentation  requested  from  vendors  as  necessary 

o  Trade  evaluation  articles  and  publications 

o  Interviews  with  vendors 

o  Interviews  with  users 

The  survey  bibliograpny  contains  all  of  the  sources  which  were  used, 

3. 1-1. 2  Survey  Report  Format 

The  format  of  the  survey  is  designed  not  only  to  give  yes/no  answers  as  to 
the  existence  of  capabilities  and  characteristics,  but  to  give  expanded 
information  where  needed  and,  very  important,  to  record  as  part  of  the 
report  the  document  from  which  the  answers  have  been  derived. 

The  first  section  of  the  survey  is  a  table  presenting  information  for  each 
of  the  DBMSs  surveyed  concerning  capabilities  and  characteristics.  Where 
desirable  or  necessary,  the  answers  in  the  survey  are  noted  for  reference 
to  the  Explanatory  Notes.  This  permits  expanded  notes  which  are  not 
artificially  constrained  by  space  limitations. 
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The  Source  Citations  portion  of  the  Survey  Report  has  a  format  which 
references  both  the  survey  item  number  and  the  bibliography  item  number. 
It  is  completed  by  filling  in  a  coded  reference  number  which  represents 
the  page  and  document (s)  (or  other  source)  from  which  the  answer  in  the 
survey  was  derived. 

The  Bibliography  portion  of  the  Survey  Report  lists  all  sources  used 
during  the  Survey  with  accompanying  codes  for  easy  reference  from  the 
Source  Citations. 

Survey  Report 

The  following  pages  contain  the  General  DBMS  Survey  Report.  They  are 
arranged  in  the  following  structure: 

o  Survey  answers  for  all  DBMSs 

o  Explanatory  Notes  for  all  DBMSs 

o  For  each  DBMS 

-  Bibliography 

-  Source  Citations 


o 


User  and  Vendor  Interviews  for  all  DBMSs 
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EXPLANATORY  NOTES :  ADABAS-M 


Software  AG  of  North  America ,  Inc. 

11800  Sunrise  Valley  Drive 

Reston,  VA  22091 

(703)  860  5050  Rex  Jaeschke 

Line  -  Comment 

6  50^  of  leasing  fee,  can  be  applied  to  permanent  license  cost 

7  Price  per  year  after  first  year.  First  year  is  included  in 
purchase  price. 

10  i*0  on  DEC  computers,  700  on  IBM  computers 

12  ADABAS-M  Introduction 

ADABAS-M  DBA  Reference  Manual 

ADABAS-M  Installation  Manual 

ADABAS-M  Application  Programmers  Manual 

ADABAS-M  Training  Workbook 

I^A  Telephone  hotline  included  in  maintenance 

2^  2000  bytes  after  compression.  255  data  items, 

25  Software  AG  calls  ADABAS  "INVERTED".  The  structure  functions  much 

like  a  relational  structure  but  is  lacking  in  several  features  such 
as  on-line  creation  and  deletion  of  data  elements  and  indexes, 
searches  on  non-indexed  data  elements  and  Joins. 

26  See  Note  25 

27  See  Note  25 

28  See  Note  25 
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>ee  Note  25 


40  Initialization  utilities  requiring  approximately  45  minutes 
must  be  run  before  the  data  base  is  available  for  loading, 

65  Limited;  Tables  of  results  and  counts  for  indexed  data  elements 
only. 

85  Hit  count,  only.  Histogram  function  available. 

86  System  Control  Utilities  manage  data  base  status,  run  time, 
and  dictionary  reporting.  May  require  DBA  privileges. 

91  Use  of  phoneticized  retrieval  reduces  errors  caused  by  spelling 
variations. 

104  Up  to  32  descriptor  fields  (keys)  per  file. 

106  Supports  backwards  compression  in  addition  to  normal  (removal  of 

blanks)  compression. 

131  Eight  volumes  maximum. 

136  Supports  repeating  groups  also. 

139  DBA  (or  privileged  user)  can  obtain  directory  information  on  each 

of  the  data  base  files. 

142  Messages  are  sent  to  the  DBA  indicating  "fill  percentage"  of  the 
log  file.  Archive  must  be  taken  when  file  is  full. 

143  Load  statistics  detail  the  type  and  number  of  disk  sectors 
required  after  loading  partial  or  complete  files. 

144  Information  can  be  printed  or  displayed  in  report  form  on  thread 
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statistics  and  run-time  statistics 


1 


150  The  system  provides  asynchronous,  multibuffered  capture  of 

compressed  before-record  images  and  data  base  update  transactions* 
Logging  is  to  a  recycling  disk  Journal,  which  supports  concurrent 
archiving. 

157  Concurrent  updates  are  prevented  by  a  record-level  lock  that  is 
timed-out  to  avoid  Interlock  (deadlock). 

169  Supports  up  to  250  threads,  up  to  8  open  files  per  thread. 

171  See  Note  157. 

186  At  the  file  level. 


I 

i. 

i. 


EXPLANATOKY  NOTES ;  BASIS 


Battelle  Columbus  Laboratories 
50b  Kin^  Avenue 
Columbus,  OH  43201 
(6l4)  424-6424  Steven  H.  Clark 


Line 

5 


Comment 

Central  System 

38,000 

Forms 

7,000 

Report 

10,000 

Monitor 

5,000 

On-Line  Input 

15,000 

Sort 

3,000 

Thesaurus 

8,000 

Profile 

8,000 

Computation 

ro.QOQ 

$104,000 

12 


BASIS  Reference  Manual 

BASIS  Data  Definition  Language  Manual 

BASIS  Utilities  Manual 

BASIS  Programmers’  Guide  to  BASLIB 

BASIS  Report  Manual 

BASIS  Thesaurus  Manual 


13  BASIS  provides  monitoring  capability  for  the  data  base 

administrator  to  compile  statistical  reports  about  command 
frequencies,  average  frequencies,  and  summarized  statistics 
on  data  base  retrievals  and  use. 


14  BASIS  Training  and  System  Maintenance  Training  included  for 
two  staff  members;  additional  training  available. 

14A  80  hours  included  with  purchase;  additional  assistance  available* 


UB  FORTRAN  85X,  ASSEMBLY  ^5%  (Source  Code  Included) 

20  IBM,  CDC,  DEC 

22  There  Is  a  limit:  1 ,879f 000,000  records  if  records  are  30,000 
characters.  If  either  of  these  values  need  increased  it  can  be 
accomplished  by  decreasing  the  other.  These  records  may  be  either 
structured  or  textual  data. 

24  See  Note  22. 

26  The  system  is  described  as  INVERTED,  this  probably  means  a 
hierarchical  data  model. 

28A  See  Note  26. 

46  FORTRAN  calls  to  BASLIB  can  be  executed  in  UNIVAC  version. 

55  Record  and  index  update  in  batch  mode  only.  On-line  requests 

for  modification  are  placed  in  a  "queue"  file  until  a  batch 
update  of  the  data  is  executed.  The  system  was  developed  for 
users  who  have  large  textual  data  bases  which  seldom  change,  but 
are  frequently  queried.  The  developers  of  BASIS  optimized 
retrieval  functions  and  made  the  query  function  easy  to  use  but 
at  a  cost  of  making  storage  of  new  information  slower  and  more 
costly. 

91  THESAURUS  converts  common  input  name  to  data  element  value. 

For  example,  AUTOMOBILE  is  indexed  data  value  and  CAR  is 
specified  as  an  alternate  for  AUTOMOBILE.  A  query  request 
for  CAR  will  be  converted  to  a  request  for  AUTOMOBILE. 

Textual  storage  of  data.  The  SCAN  command  permits  loction  of 
unstructured  text  containing  phrases,  words,  or  groups  of  words, 
Sets  of  words  close  together  can  be  located  such  as  "RED  and  BUICK 
within  5  words  of  each  other". 
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The  indexes  are  restructured  at  various  tliLes  by  "batch"  reqi.es* 
"Look-ups"  between  data  modification  and  index  restructure  requi/< 
search  of  both  the  Inverted  file  and  the  update  queue. 


See  Note  22 


See  Note  13* 


PROFILE  is  one  of  the  add-on  BASIS  options.  It  saves  portions 
of  sessions  or  an  entire  session  for  later  re-execution. 

No  Deadlock  provision  needed  because  updates  are  placed  on 
"Queue"  file  for  later  data  base  change. 


Test  of  existence  of  required  fields,  range  checking,  others. 
There  are  also  table  lookups,  data  element  cross  referencing. 


EXPLANATORY  NOTES:  IDM-500 


Britton  Lee,  Inc 

Albright  Way 

Los  Gatos,  CA  95030 

(408)  378-7000  Mark  Willner 

The  Intelligent  Database  Machine  (IDM),  manufactured  by  Britton  Lee  Inc., 
is  a  data  base  machine ,  incorporating  Special  Purpose  Function 
Architecture  (SPFA)  devoted  to  the  efficient  management  of  data.  The 
computer  contains  complete  data  management  system  software. 

The  IDM  does  not  include  the  interface  necessary  for  movement  of  requests 
from  the  host  to  the  IDM  or  from  the  IDM  to  the  host.  This  software  must 
be  obtained  in  addition  to  the  IDM  by  OEM  dealers  or  in-house  development. 
At  the  present  time  two  UNIVAC/IDM  general  interfaces  are  being  developed 
by  Amperif  and  Interscience.  Writing  the  interface  between  the  existing 
AMIP  system  and  the  existing  IDM  DBMS,  would  require  the  following  steps: 

o  Communicate  with  end-user  programs 

o  Translate  user  commands  to  IDM-internal  form 

o  Send  commands  to  the  IDM 

o  Receive  results  from  the  IDM 

o  Format  the  results  and  transmit  to  the  end-user  program 

Because  there  is  an  OEM  interface  level  between  the  IDM-500  and  the  AMIP 
computer  answers  to  many  of  the  questions  in  this  survey  have  not  been 

finalized.  OEM  dealers  might  not  implement  software  interface  to  all 

features  of  the  IDM.  Therefore,  ”yes"  answers  to  many  questions  in  the 
survey  are  based  upon  full  use  of  the  capabilties  of  the  IDM-500. 

Other  OEMs  have  developed  (or  are  developing  IDM  interfaces  to  IBM  370, 

30XX,  43XX,  and  Series  1  computers  along  with  Datapoint,  VAX,  and  Z80  and 

poosibly  other  computers. 
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Line 


Comnient 


5  $50,000  for  the  minimum  machine.  The  Database  Accelator  option  is 

$10,000.  This  is  a  likely  recommended  option,  but  as  of  this  dr.ite 
it  has  not  become  avajllable.  With  all  options  the  IDM  costs 
about  $200,000.  Software  for  the  host  computer  is  not  included 
in  the  above  prices. 

7  90  day  warranty  (limited). 

12  Software  Reference  Manual 

OEM  dealers  supply  additional  manuals. 

Training  classes  for  2  persons  included  if  IDM  purchased  directly 
from  Britton-Lee.  If  obtained  from  OEM  then  training  based  upon 
policies  of  OEM  dealer. 

I4a  Based  upon  policies  of  OEM  dealer. 

20  Any  computer  which  supports  an  RS-232,  GPIB  or  IEEE-^88  interface 

22  The  IDM  will  manage  50  data  bases.  Each  data  base  can  have  up  to 
32,000  relations  (files).  There  may  be  up  to  2  billion  tuples 
(data  items)  per  relation. 

23  See  Note  22 

54  Not  supplied  by  Britton  Lee,  OEM  vendors  have  additional 
interfaces.  Can  be  invoked  via  any  language  which  contains 
a  standard  CALL  statement. 

55  Britton  Lee  developed  language  IDL  which  is  similar  to  the  INGRES 
QUEL.  The  machine  is  normally  sold  by  OEM  vendors  who  may  supply 
IDL  ur  some  other  language  interface  made  special  for  the 
application.  (Two  vendors  are  adding  these  interfaces  for 
IDM-500/UNIVAC  linkups. 

( " 


85 


Count,  average,  min,  max,  sum,  existence 


106  When  possible,  the  system  blocks  tuples  based  upon  the  clustered 
(or  primary)  Index. 

161  Access  can  be  limited  to  stored  queries. 

167  Has  a  delete  duplicate  silently  "(<?I>)  option  as  well  as 

enforcing  uniqueness. 

delations  have  creation  date  and  obsolete  data  checks. 
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EXPLANATORY  NOTES:  DMS-1 1 00 


Sperry  UNIVAC 
8008  Westpark  r-ive 
McLean,  VA  22102 

(703)  556-530^  J.  Winston  Copeland 
(215)  5^2-3278  Jerry  Bill 


Line 

Comment 

6 

CMS 

$425 

QPL  1100 

365 

DD 

365 

RPL  1100 

240 

$1395 

12  DMS1100  Schema  Definition 

DMS1100  Sub-schema  Definition 
DMS1100  COBOL  Data  Manipulation  Language 
DMS1100  FORTRAN  Data  Manipulation  Language 
DMS1100  PL/1  Data  Manipulation  Language 

DMS1100  Data  Management  Systems;  System  Support  Functions 
DMS1100  Data  Management  Systems;  Operator  Reference 
DMS1100  Data  Management  Systems;  Summary 

17  The  amount  of  memory  is  dependent  upon  the  overlay  description. 
A  15K  structure  is  minimal,  but  many  users  find  that  ^OK 
structures  lead  to  optimal  performance. 

22  A  data  base  may  contain  68  billion  records. 

29  DMS-1100  is  a  pointer  based  system,  but  it  contains  an  index 
sequential  feature. 

30  DMS-1100  orivudes  via  the  Data  Dictionary  System  a  means  of 
centralized  description,  location  and  control  of  the  various 
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elements  within  a  user  data  base  environment.  The  DDS  provides 
the  user  with  facilities  which  can  be  used  to  describe  data  so 
that  its  representation  and  its  intended  use  in  the  real  world 
is  clear.  It  provides  a  means  to  describe  the  relationship 
between  data  users  and  the  data  base  by: 

o  Providing  a  storage  place  for  the  actual  meaning  of  the 
various  data  elements  as  v/ell  as  a  description  of  their 
physical  characteristics  and  storage  layout. 

o  Describing  the  Interaction  between  data  and  the  data  base 
processors,  in  order  to  provide  information  for  performance 
tuning. 

o  Providing  data  base  design  aids  through  impact  reports  on 
proposed  changes. 

o  Generating  various  reports  describing  the  data  and  their 

locations  in  the  data  base  environment  or  in  conventional  files. 

91  The  Remote  Processing  System  RPS  1100  is  an  End  User  Facility 
which  provides  a  screen-image  oriented  interface  to  files 
maintained  within  the  data  basu  RPS  1100  allows  the  end  user 
to  view  a  file,  manipulate  the  screen  image  of  the  file,  and 
update  the  file. 


99 A  Though  not  specified  in  the  CODASYL  Report,  the  location  mode 

of  index  sequential  has  been  included  by  Sperry  Univac  at  the 
^  request  of  the  users. 

j  119  Called  "Within  Record  Name". 

if 

II43  The  following  file  statistics  can  be  printed: 

Total  number  of  page  references  (i.e.,  counter  incremented  for 
each  page  referenced  during  DMR  search) 
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Total  number  of  pages  altered 

Total  number  of  page  I/Os  (l.e.,  page  reads) 

Total  number  of  overlay  I/Os  (printed  only  for  segmented  DMR) 

The  following  performance  statistics  can  be  printed: 

Total  number  of  times  queued  and  the  time  spent  in  the  queue 
(in  milliseconds)  for  various  reasons. 

Start  time/date 
Ending  time 

Total  number  of  imparts 
Total  number  of  departs 

Total  number  of  main-to-overlay  references 
Total  number  of  overlay-to-overlay  references 

149  Multiple  data  base  permits  processing  in  test  mode, 

187  Existence  of  required  fields. 
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EXPLANATORY  NOTES :  SQL/DS 


International  Business  Machines  Corporation 

Data  Procesing  Division 

1133  Westchester  Avenue 

White  Plains,  NY  10604 

(914)  696-1900  Mike  Bushal 

Line  Cominent 

2  Structured  Query  Language/Data  System  (SQL/DS)  is  scheduled  to 

become  available  during  1982.  It  is  based  upon  a  development 
effort  called  "System  R".  The  System  R  research  has  been 
completed. 

SQL/DS  has  previously  been  called  by  several  other  names  in 
addition  to  System  R:  SEQUEL;  SQL;  SQL  II 

4  A  basic  license  fee  costs  $300  per  month  plus  a  monthly  licensed 

program  support  charge  of  $105. 

12  Currently  available  is:  IBM  Program  Product  SQL/Data  System 
Concepts  a.’td  Facilities. 

Additional  manual  should  become  available  near  the  system  release 
date. 

17  The  system  nucleus  with  CICS  and  CSAM  needs  1,1 OOK  bytes  plus 
160K  bytes  for  each  user.  If  no  overlays  2  megabytes  are  used. 
IBM  recommends  a  minimum  of  2  megabytes  of  memory  for  effective 
use  of  SQL/DS 

34 A  The  user  can  update  his  view  of  the  data  base  model. 


86A 


The  user  can  see  the  on-line  reference  information  by  using  the 
HELP  command  and  specifying  the  topic  of  interest. 


EXPLANATORY  NOTES :  RAPPORT 


Logica  Ipc, 

31*1  Madison  Avenue 
New  York,  NY  10017 
(212)  599-O828  Richard  Gostanian 

Line  Comment 

5  License  rather  than  purchase.  Unbundled  parts  are: 


Nucleus  with  preprocessor  for  FORTRAN  or  COBOL  -  $12,000 
Second  preprocessor  6,000 
Interactive  Query  Language  6,000 
Backup  and  Recovery  6,000 
Multi-User  Concurrency  Control  8,000 
Data  Security  Package  6 ,000 

$4^1,000 


7  1%  of  license  fee  after  first  year. 

10  80  world  wide,  1  in  USA,  3  are  UNIVAC. 

12  RAPPORT  User  Manual 

Interactive  Query  Language  Manual 
Designing  and  Using  a  Database 
RAPPORT  COBOL  User  Manual 

20  VAX-11,  PDP-11,  ICL  1900,  ICL  2900,  IBM  370,  GEC  4000,  Data  General 

NOVA  and  ECLIPSE,  Honeywell  66/60,  Harris,  Burroughs  B6700,  and 
SEL.  Logica  will  install  RAPPORT  on  virtually  any  machine  as  part 
of  the  normal  license  price. 

30  Some  features  at  current  time;  complete  Data  Dictionary  will  be 
implemented  in  the  near  future. 

59  The  OR  operator  will  be  implemented  soon. 


if 
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60  RAPPORT  does  not  directly  support  cartographic  operations,  but  the 
first  use  was  in  "war  games  simulation"  for  the  British  Ministry 
of  Defence. 

79A  AND  and  NOT  currently;  OR  will  be  added  shortly. 

79B  Results  cannot  be  found  in  sorted  order  or  by  partial  sort 

(i.e. ,  name  =  Results  found  by  other  criteria  can  be 

set  in  temporeiry  storage  then  sorted  and  returned  to  the  requestor 
in  sorted  order. 

80  See  Note  60. 

99A  System  uses  Hash  techniques  to  store  and  locate  index  entries 
and  data,  but  user  view  is  relational. 

120  See  Note  99A. 

180  Intersection  of  Fields  and  Records. 

181  via  PASSWORDS 

182  If  read  access  is  not  available  to  some  field  then  its  value  is 
replaced  with  default  value.  No  error  message  is  iciveii. 

Incorrect  results  possible  when  default  is  used  in  later 
calculations. 
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EXPLANA iORY  NOTES :  SIBAS 

Shipping  Research  Services  A/S 
2600  Capital  Natlor*al  Bank  Plaza 
333  Clay  Street 
Houston,  TX  77002 
(716)  658-8823  Johannes  Omvik 

Line  Comment 

5  $25|C00  for  non-profit  organization* 

12  User  Manual,  DBA  Manual,  Installation  Guide 

20  IBM,  DEC-10,  CDC,  ND-10,  PRIME 

27  Developers  did  not  follow  CODASYL  specification  where  they  felt 
the  CODASYL  did  not  contribute  to  the  most  useful  DBMS,  The 
system  Includes  the  CODASYL-78  addition  of  involuted  sets. 

29  SIBAS  is  a  pointer  based  system,  but  it  contains  an  Indexed 
feature. 

A  Data  Manipulation  language  exists  for  COBOL.  Other  host 
languages  require  CALLs. 

55  Limited;  There  is  an  interactive  query-update  language,  SIBINTER. 

It  encompasses  only  the  calls  to  the  host  language  SIBAS 
manipulation  modules  in  a  dialogue  form  more  convenient  to  the  user 

60  SIBAS  has  been  used  in  map  digitizing  applications. 

76  See  Note  55. 

91  Involuted  sets.  This  permits  set  members  to  be  the  same  record 
type  as  the  set  owner. 
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The  REMEMBEH  verb  enables  the  user  to  build  a  log  table  of 
desirable  records  for  later  use. 

155  Updates  are  made  to  log  fllCi  then  a  "finish"  command  causes  the 
transaction  to  be  automatically  copied  to  the  data  base. 

170  Prevention  of  deadlocks  by  means  of  the  "keep  list" 

(CODASYL  commands: COMMIT/ROLL-BACK ;SIBAS  commands: LOCK/UNLOCK) 

181  Privacy  locks  on  items  in  record. 
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EXPLANATORY  NOTES:  SYSTEM  2000 


INTEL  Corporation 

1620  Elton  Road 

Silver  Springs,  MD  20903 

(301)  ^31-1200,  Jim  Landerkin 

Line  Comment 

5  1981  price  $108,000  for  a  "typical"  system 

1982  price  not  expected  to  differ  greatly 

12  DEFINE 

ACCESS  and  QUEUE 

PLEX  Users  Guide 

Messages  and  Codes 
System  Support  Manual 
Report  Writers  Guide 
Syntax  Guide 

14A  A  customer  hotline  service  is  provided  and,  in  addition, 

each  customer  is  assigned  to  a  Customer  Service  Representative 
(CSR)  who  provides  personalized  customer  service  and  a  focal 
point  for  all  communications.  ; The  CSR  becomes  acquainted  with  the 
customer’s  particular  environment,  ensuring  that  all  support 
efforts  are  in  line  with  the  customer’s  specific  support  needs. 

18  Any  hardware  which  supports  EXEC  8. 

27  Hierarchical,  but  can  be  viewed  as  network. 

28  Hierarchical,  but  can  be  viewed  as  relational. 

28 A  See  Notes  27  and  28. 

30  The  Data  Dictionary  exists  in  the  nucleus. 


70  Both  QUEST,  a  normal  query  language  and  QUEX,  a  version  of 
Query  by  Example. 

86  99  reports  can  be  obtained  with  single  pass  of  portion  of  data 

base. 

90  One  copy  of  System  2000  needed  in  network. 

90A  Exits  exist  to  permit  user  developed  controls  to  be  part  of 
SYSTEM  2000: 

Enhanced  or  specialized  security  processing. 

Dynamic  data  value  encoding. 

Creation  of  user-specific  Mialects*  for  the  FLEX  data 
manipulation  language. 

Direct  SYSTEM  2000  interface  to  site-developed  software  such 
as  editing  and  encryption  routines. 

SYSTEM  2000  interface  with  other  software  packages  such  as 
financial  accounting,  manufacturing,  statistical,  or  graphics 
systems. 

107  Network  relationships  can  be  dynamically  established.  It  is 
not  clear  whether  chains  are  used. 

1^3  Report  of  index/ table  skewness  and  internal  inconsistencies. 

149A  Full  automatic  data  base  recovery  for  system  or  program  failure. 
Data  integrity  is  ensured  even  if  one  or  more  programs  fail  with 
concurrent  batch  and  on-line. 
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EXPLANATORY  NOTES;  MRDS 


Horioyweli  Information  Systoms,  Inc. 

200  Smith  .Street 

Waltham,  MA  OPIhM 

(617)  895-32^7 

Line  -  Comment 

2  Multics  Relational  Data  Store 

9  Release  date  of  ^^DBM  (Multics  Data  Base  Manager) 

12  DBA  Guide,  MRDS  Reference  Manual,  LINUS  Reference 

Manual,  MRPG  Reference  Guide 

21  Supports  up  to  64  data  bases 

34  A  data  submodel  may  be  created  at  any  time  by  either  a  user  or  the 
DBA,  where  the  data  submodel  must  be  a  subset  and/or  a  renaming  of 
an  existing  data  base.  When  a  data  submodel  defines  a  relation  as 
being  a  subset  of  the  actual  relation  in  the  data  base,  two 
restrictions  exist: 

1  -  deleting  tuples  from  such  a  relation  is  not  permitted  when 

using  the  submodel. 

2  -  storing  tuples  into  such  a  relation  is  not  permitted  when  using 

the  submodel . 

34a  No  more  than  20  temporary  relations  may  exist  for  one  user  at  a 
time.  The  accessing  of  temporary  relations  is  restricted  to 
retrieve  and  delete  temporary  relation  operations  only. 

41  The  LINUS  store  request  may  be  used  to  load  relations  from  raw  text 
files  if  the  format  of  the  files  is  identical  to  the  format  of  the 
relations. 

42  The  dsl-$store  subroutine  is  available  for  writing  and  executing  a 
load  progrm  designed  to  read  raw  data  from  existing  files  and 
store  it  into  the  data  base. 

54  MRDS  is  callable  from  any  Multics  language  supporting  a  CALL 

interface  (including  APL,  BASIC,  etc.)  and  is  additionally  callable 
from  Multics  Command  level  via  the  MRDS-CALL  command. 


Line  -  Comment 


6^  Retrieve  and  store  operations  are  the  only  data  base  operations 
that  operate  on  one  tuple  at  a  time.  A  single  delete  or  modify 
operation  on  the  other  hauid  may  potentially  delete  or  modify  every 
tuple  in  the  data  base. 

78  Set  operators  are  provided  which  correspond  to  the  commonly  defined 
operators  of  union,  Intersection,  and  difference. 

85  Sum,  Ave,  Count,  etc.,  available  through  LINUS,  other  built-in 
functions  include;  absolute,  after,  before,  ceiling,  concatenate, 
floor,  index,  modulus,  reverse,  round,  search,  substring,  and 
verify. 

86  Through  the  Level  68/DPS  Report  Program  Generator. 

86a  A  help  facility  is  available  for  LINUS  (logical  inquiry  and 
update  system) . 

88  Standard  Multics  sort  commands  and  subroutines  are  available  for 
users  desiring  sorted  data. 

139  Tools  exist  to  monitor  data  base  usage  from  various  aspects. 

149a  Using  Multics  backup  retrieval  mechanisms,  recovery  is  provided 
after  a  system  fEilIure  or  when  a  disk  has  been  damaged. 

150  See  note  149a. 

158  Data  base  access  is  shared  unless  the  data  base  is  opened  in  an 
exclusive  mode. 

170  When  opening  more  than  one  data  base,  the  openings  must  be  done 

simultaneously  within  the  same  call  to  MRDS  to  prevent  a  deadlock 
situation.  Although  a  user  may 'repeatedly  set  and  delete  scope 
while  the  data  base  is  open,  the  user  must  delete  all  scope  before 
setting  a  new  scope  to  avoid  potential  deadlock. 

173  Standard  Multics  security  features(  MULTICS  security 

ranks  at  or  near  best). 

187  If  an  incomplete  tuple  is  being  stored  (i.e.,  a  tuple  with  one  or 

more  unknown  attribute  values)  the  user  must  insert  "null*^  values 
in  the  tuple  being  stored  in  order  to  prevent  a  shifting  of 
attribute  values  into  the  wrong  attribute  field.  One  rule  used 
in  this  case  is  to  substitute  a  blank  for  fields  requiring 
alphabetic  data  and  a  -1  for  an  attribute  requiring  numeric  data. 
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BIBLIOGRAPHY :  ADABAS-M 


CQdg  Tltl_e  or  Description 

A1  ADABAS-M  Introduction,  Software  AG. 

A2  ADABAS-M  Brochure,  Software  AG. 

A3  "ADABAS-M",  DATAPRO  RESEARCH  CORP. ,  SEPT.  1979. 

Ai|  DBMS  Test  and  Evaluation  for  the  PACOM  Data  Systems  Center, 

MITRE  Corp.,  1979 

A5  Classic  Fox  DBMS  Tradeoff  Study  Report,  Appendix  F,  August  1980. 
A6  ADABAS-M  Reference  Data,  Software  AG. 

A7  Discussion  with  vendor. 

A8  ADASCRIPT-M  Reference  Manual,  Software  AG. 

A9  ADABAS-M  Application  Programmer’s  Manual,  Software  AG. 

A10  ADABAS-M  DBA  Reference  Manual,  Software  AG. 

All  ADABAS-M  Installation  Manual,  Software  AG. 

A12  Computerworld,  April  6,  1981. 

A13  PACOM  Data  Systems  Center  Evaluation  Report,  MITRE 
v-^rp,,  1979. 

AU  "DATAMATION",  Sept.  1981,  Vol.  27,  Number  10. 

A15  "ICP  INTERFACE"  Winter  1981,  Vol.  6,  Number  M. 

A16  Authorized  ADP  Schedule  Price  List,  Software  AG. 
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SOUHCE  CITATIONS: 


ADAJiAS-M 


ENTRY 

REFERENCE 

ENTRY 

REFERENCE 

ENTRY 

REFERENCE 

ENTRY 

:.C£S 

1 

44 

A15:95 

99 

146 

.'9:99 

2 

45 

99a 

147 

3 

46 

A2 

100 

148 

li 

47 

A2 

101 

149 

5 

Al6 :22 

48 

A2 

102 

149a 

A2;A3 

6 

A16 :22 

49 

A2 

103 

A9:99 

150 

A3;A10 

7 

A16 :22 

50 

104 

A15:95 

151 

A3 

8 

105 

A1 :11 

152 

A12 

9 

A2,A3 

52 

106 

A2;A3 

153 

A10:11 ,21 

10 

A15:95,97 

53 

A2 

106a 

154 

A7 

10a 

54 

107 

A1 :29 

155 

11 

55 

108 

A1 :29 

156 

12 

56 

109 

A1 :29 

157 

A1  :27 

13 

57 

110 

A1 :29A1 :29158 

A1 :27 

14 

A16:22 

58 

111 

A1 :29 

159 

14a 

59 

A8;A9:12 

112 

A1 :29 

160 

14b 

A2 

60 

113 

A1 :29 

161 

A10:14 

15 

61 

A9 

114 

A1:29 

162 

16 

62 

Al:19 

115 

A1 :29 

163 

A1 :27 

17 

A3 

63 

A1 :19 

116 

A1 :29 

164 

18 

64 

A1 : 19 

117 

A1 :29 

165 

19 

A15:95 

65 

A13:2-8 

118 

A1:29 

166 

A15:95 

20 

66 

A2;A9 

119 

167 

A15:95 

21 

76 

a8 

120 

168 

A15:95 

22 

A13:I-23 

77 

121 

169 

A15:95 

23 

A13:I-23 

78 

A6;A8 

122 

170 

24 

A1 : 12;A9 

79 

123 

171 

A1 :27 

24a 

79a 

A15:95 

124 

172 

24b 

79b 

125 

A1:12;A3 

173 

25 

80 

126 

A1 :12;A3 

174 

26 

81 

127 

A1:5,29 

175 

27 

82 

A9:29 

128 

176 

A13:I-22 

28 

83 

129 

177 

28a 

84 

130 

178  , 

A1:27 

29 

85 

A1:18:A8 

130a 

179 

A13:I-22 

30 

86 

A1 :25;A3 

131 

180 

31 

86  a 

132 

A10:17 

181 

32 

87 

133 

182 

A9:27;A10 

33 

A10:5,9 

88 

134 

A9:16 

183 

34 

A10:5,9 

89 

A9:5;A10:6135 

A9:16 

184 

A9:27;A10 

34a 

90 

136 

A3;A5 

185 

35 

90a 

137 

186 

A10:5,23 

36 

91 

138 

187 

37 

92 

139 

A9:5 

188 

38 

A3 

93 

140 

189 

39 

A3 

94 

141 

190 

40 

95 

A1 :8,12 

142 

A10:17 

191 

41 

96 

143 

A10:6,27 

192 

42 

97 

A1:29,A3 

144 

193 

43 

98 

A9:18,A10 

145 

194 

BIBLIOGRAPHY :  BASIS 


Code 

Title  or  Description 

B1 

DATAPRO  Reports  "BASIS",  Oct. 

1980. 

B2 

Auerbach  Publishers  "BASIS". 

B3 

What  is  BASIS. 

Bk 

BASIS-Battelle’s  Data  Management  System  "Executive  Summary 

B5 

BASIS  Installation  Support. 

B6 

ICP  Interface  "BASIS",  Winter 

1981. 

B7 

Discussion  with  Vendor. 

3-41 


SOURCE  CITATIONS:  BASIS 


ENTRY 

REFERENCE 

ENTRY 

REFERENCE 

ENTRY 

REFERENCE 

ENTRY 

1 

44 

99 

146 

2 

45 

99a 

B7 

147 

3 

B3 

46 

B7 

100 

148 

i) 

47 

B7 

101 

149 

B1 : 

5 

48 

102 

I49a 

6 

49 

103 

150 

B2 

7 

50 

104 

B3 

151 

8 

51 

105 

B3 

152 

9 

B4 

52 

106 

153 

10 

B4 

53 

106a 

154 

B2 

10a 

54 

B7 

107 

155 

B2 

11 

55 

B2 

108 

156 

12 

B3 

56 

109 

157 

13 

B3 

57 

B3 

no 

158 

14 

B5 

58 

B6 : 87 

111 

159 

14a 

B5 

59 

B3 

112 

160 

14b 

B3 

60 

113 

161  . 

15 

61 

114 

162  ' 

16 

B3 

62 

B3 

115 

163 

17 

63 

B3 

116 

164 

18 

64 

B3 

117 

165 

19 

B3 

65 

118 

166 

20 

B1 

66 

119 

167 

B7 

21 

76 

B3 

120 

168 

22 

B7 

77 

121 

169. 

23 

78 

122 

170 

24 

B7 

79 

B6:87 

123 

171 

24a 

79a 

B3 

124 

172 

24b 

79b 

B3 

125 

173 

25 

80 

126 

174 

26 

B3 

81 

127 

175 

B1 : 

27 

B3 

82 

B3 

128 

176 

28 

B3 

83 

B3 

129 

177 

28a 

B3 

84 

B2 

130 

178 

B1 : 

29 

B3 

85 

B3 

130a 

179 

B1; 

30 

86 

B3 

131 

180 

31 

B3 

86a 

B4 

132 

181 

32 

B3 

87 

133 

182 

B4: 

33 

88 

B3 

134 

B7 

183 

B4: 

34 

89 

B3 

135 

B7 

184 

B4: 

34a 

90 

136 

B7 

185 

35 

90a 

137 

186 

36 

91 

B3;B6:87 

138 

187 

37 

92 

139 

188 

38 

B3 

93 

140 

B1  :d 

189 

B4: 

39 

B3 

94 

141 

190 

40 

95 

B1 

142 

191 

B4: 

41 

96 

B7 

143 

B3 

192 

42 

97 

144 

193 

43 

98 

B1 

145 

194 

S-U2 


BIBLIOGRAPHY:  IDM-500 


Cod€  litig  or  geacrlptlcn 

11  Discussion  with  OEM,  Interscience. 

12  Discussion  with  OEM,  AMPERIF 

13  IDM-500  Intelligent  Database  Machine,  Product  Description. 

14  IDM-500  Intelligent  Database  Machine,  Software  Reference  Manual 

15  Design  Decisions  for  the  Intelligent  Data  Base  Machine  by 
Robert  Epstein  and  Paula  Hawthorn,  APIPS  Conference  Proceedings, 
Volume  49.  Proceedings  National  Computer  Conference  1980 

16  Computer  World,  Jan.  5$  1981,  "The  Looming  Battle  Between  Data 

Base  Machines  and  Software  Data  Base  Management  Systems"  by 
Vincent  C.  Rawzino. 

17  Discussion  with  Vendor. 


3-43 


SOURCE  CITATIONS:  IDM-500 
ENTRY  REFERENCE  ENTRY  REFERENCE  ENTRY  REFERENCE  ENTRY  hr.r):i>FJ;CE 


1 

44 

2 

45 

3 

46 

k 

47 

5 

48 

6 

49 

7 

50 

8 

51 

9 

52 

10 

53 

10a 

54 

11 

55 

12 

56 

13 

57 

14:4-1 

111 

58 

14:4-1 

lHa 

59 

13:12 

Ub 

60 

15 

61 

13:14 

16 

62 

13:14 

17 

63 

13:14 

18 

64 

19 

65 

20 

66 

21 

76 

22 

13:3 

77 

23 

13:3 

78 

211 

13:3 

79 

13:12 

2lla 

79a 

2llb 

13:3 

79b 

13:13 

25 

80 

26 

81 

27 

82 

28 

13:3 

83 

13:12 

28a 

84 

14:3-1 

29 

85 

13:12 

30 

86 

31 

86  a 

32 

87 

33 

88 

34 

89 

34a 

14:7-40 

90 

35 

90a 

36 

I4:A-1 

91 

37 

92 

38 

93 

39 

94 

40 

95 

41 

96 

42 

97 

43 

98 

99 

146 

99a 

14:1-7 

147 

100 

148 

101 

149 

14:7-71 

102 

149a 

103 

150 

104 

151 

13:16 

105 

152 

106 

153 

14:7-53 

106  a 

13:14 

154 

13:15 

107 

155 

14:7-24 

108 

156 

109 

157 

no 

158 

in 

159 

112 

160 

113 

161 

114 

162 

115 

163 

116 

164 

117 

165 

118 

166 

119 

167 

120 

168 

15 

1^1 

169 

15 

122 

170 

15 

123 

171 

15 

124 

172 

125 

173 

126 

174 

127 

175 

128 

176 

I4A-4 

129 

177 

130 

178 

130a 

179 

131 

14:3-10 

180 

I4A-4 

132 

181 

133 

182 

14:7-75 

134 

I4:A-3 

183 

14:7-75 

135 

I4:A-2 

184 

14:7-75 

136 

I4:A-3 

185 

137 

186 

138 

187 

139 

188 

140 

189 

141 

190 

142 

191 

I4:A-3 

143 

192 

l4:A-2 

144 

193 

I4:A-3 

145 

194 

I4:A-3 

5 


) 


BIBLIOGRAPHY :  DMS- 1 1 00 


g,o<ig  Iltlg,,gr.  I>g8gr.lPViQB 

D1  DATAPRO  Reports,  IMS  1100.  April  1981 

D2  Auerbach  Publishers,  DMS  1100. 

D3  Sperry  UNIVAC  Series  1100  Schema  Definition 

D4  Sperry  UNIVAC  Series  1100  Support  Functions 

D5  Sperry  UNIVAC  Series  1100  Support  COBOL  DML 

D6  Sperry  UNIVAC  Series  1100  Program  Product  Specification  DMS  1100 

D7  Discussion  with  Vendor 

D8  Sperry  UNIVAC  1100  Series  Data  Management  System  DMS  1100 
Software  Abstract 

D9  Computer  World,  June  6,  1981  "QPL". 

D10  UNIVAC  Progam  Product  Specification  Data  Dictlonay 

Dll  Sperry  UNIVAC  Series  1100  Support  FORTRAN  DML 


3-A5 


SOURCE  CITATIONS: 

ENTRY  REFERENCE  ENTRY  REFERENCE  ENTRY 


1 

44 

D6 

99 

2 

45 

99a 

3 

46 

D6 

100 

i) 

47 

D6 

101 

5 

48 

102 

6 

D1 

49 

D6 

103 

7 

50 

10^4 

8 

51 

105 

9 

D1 

52 

106 

10 

D1 

53 

106  a 

10a 

54 

107 

11 

55 

108 

12 

D2 

56 

109 

13 

57 

Dll: 3-33 

110 

14 

D2 

58 

D8:33 

111 

I4a 

59 

Dll; 3-33 

112 

14b 

60 

113 

15 

61 

16 

D2 

62 

D8:18 

115 

17 

D7 

63 

D8:18 

116 

18 

D2 

64 

D8:17 

117 

19 

D2 

65 

118 

20 

D2 

66 

119 

21 

76 

D6:23 

120 

22 

D8:33 

77 

121 

23 

78 

Dll : 3-33 

122 

24 

D8:33 

79 

D8:33 

123 

24a 

79a 

Dll:  3-33 

12^ 

24b 

79b 

125 

25 

80 

126 

26 

D6 

81 

127 

27 

D6 

82 

D6 

128 

28 

D6 

83 

D6 

129 

28a 

D6 

84 

D8:34 

130 

29 

D3:6-2 

85 

D3:3-66 

130a 

30 

DIO 

86 

D9 

131 

31 

D3 

86a 

132 

32 

D3 

87 

133 

33 

D3 

88 

13^ 

34 

D3 

89 

D8:46 

135 

34a 

90 

136 

35 

D3:J-1 

90a 

137 

36 

D5:1-1 

91 

138 

37 

92 

139 

38 

D6 

93 

1^40 

39 

D6 

94 

U1 

40 

95 

142 

41 

96 

D2 

143 

42 

D6:17 

97 

D2 

144 

43 

98 

D2 

145 

>46 


BIBLIOGRAPHY :  SQL/DL 


Code  Title  or  DescrlPtloji 

SQ1  DATAPRO  Software  News  Volume  7,  Number  3,  March  198K 
SQ2  IMS  Management  Feb  9,  1981 i  "IBM  Uncorks  First  Relational 
DBMS  for  370/4300  Users." 

SQ3  IBM  Program  Product  SQL/Data  System  Concepts  and  Facilities. 
SQ4  Software  News  Dec  7,  1981,  "Practically  Speaking  Relational 
DBMS  Exist",  by  Marlene  Brown. 

SQ5  Information  System  News  August  24,  1981  "Hardware  Curbs 

Relational  Systems". 

SQ6  Deleted 

SQ7  Discussion  with  vendor. 


SOURCE  CITATIONS:  SQL/DS 


ENTRY 

REFERENCE 

ENTRY 

REFERENCE 

ENTRY 

REFERENCE 

ENTRY 

REFERENCES 

1 

SQ3:32 

99 

SQ3:16 

146 

SQ3:17 

2 

SQ5:12 

1*5 

99a 

147 

SQ3:17 

3 

46 

100 

148 

4 

SQ1 

47 

SQ3:32 

101 

149 

5 

SQ1 

48 

102 

149a 

6 

SQ1 

49 

SQ3:32 

103 

150 

7 

SOI 

50 

104 

SQ3:16 

151 

8 

51 

105 

SQ3:16 

152 

9 

52 

106 

153 

10 

53 

SQ3:32 

106a 

SQ3:16 

154 

SQ3:51 

10a 

54 

107 

155 

SQ3:52 

11 

55 

108 

156 

12 

56 

109 

157 

13 

57 

SQ3:17 

110 

158 

14 

58 

SQ3:58 

111 

159 

I4a 

59 

SQ3:58 

112 

160 

14b 

60 

113 

161 

15 

61 

114 

162 

16 

SQ3:1 

62 

SQ3:15 

115 

163 

17 

SQ7 

63 

SQ3:15 

116 

164 

18 

64 

SQ3:16 

117 

165 

19 

SQ3:1 

65 

118 

166 

20 

66 

119 

167 

21 

76 

SQ3:76 

120 

168 

22 

77 

121 

169 

23 

78 

122 

170 

24 

79 

SQ3:15 

123 

177 

24a 

79a 

SQ3;15 

124 

172 

SQ3:54 

24b 

79b 

SQ3 : 1 8 

125 

173 

25 

80 

126 

174 

26 

81 

SQ2:l 

127 

175 

27 

82 

128 

176 

28 

SQi( 

83 

129 

177 

28a 

84 

SQ3:26 

130 

178 

29 

85 

SQ3:14 

130a 

179 

SQ3:47 

30 

86 

SQ3:22 

131 

180 

31 

86  a 

SQ3:29 

132 

181 

32 

SQ3:'*7 

87 

133 

182 

SQ3:46 

33 

88 

134 

183 

SQ3:46 

34 

89 

SQ3:61 

135 

184 

SQ3:46 

34a 

90 

136 

SQ3:8 

185 

35 

90a 

137 

SQ3:8 

186 

36 

91 

138 

187 

37 

92 

139 

SQ3:49 

188 

38 

SQ3:57 

93 

140 

189 

39 

SQ2:1 

94 

141 

190 

40 

95 

142 

191 

SQ:7 

41 

SQ3:38 

96 

143 

192 

SQ3:9 

42 

97 

144 

SQ3:63 

193 

43 

98 

145 

194 

3-48 


BIBLIOGRAPHY :  RAPPORT 


HI  DATAPRO  Jcin.  1961 

R2  Deleted 

R3  RAPPORT  (product  description) 

R4  RAPPORT  Price  List  July  I98I 

R5  RAPPORT  Users  Manual 

R6  RAPPORT  Designing  and  Using  a  Database 

R7  Discussion  with  Vendor 

R8  Software  News  Dec  7,  1981,  p.  47.  "Practically  Speaking  Relation 
DBMS  Exist”  by  Mau'lene  Brown 


3-49 


SOURCE  CITATIONS:  RAPPORT 


ENTRY  REFERENCE  ENTRY  REFERENCE  ENTRY  REFERENCE  ENTRY  REFERENCE 


1 

44 

2 

45 

3 

46 

R3 

4 

47 

R3 

5 

R4:1 

48 

6 

49 

7 

R4:1 

50 

8 

51 

9 

52 

R3 

10 

R8:47 

53 

10a 

54 

11 

55 

12 

56 

13 

57 

R3:3-11 

U 

58 

R3:3-6 

Ua 

59 

R7 

Ub 

60 

15 

61 

16 

R3 

62 

R3:3-6 

17 

R7 

63 

R3:3-14 

18 

64 

19 

65 

20 

R3 

66 

21 

76 

22 

77 

23 

78 

R8:47 

2k 

R6:4-3 

79 

24  a 

79a 

R3 

24b 

79b 

R5:2-3 

25 

80 

26 

81 

27 

82 

R3 

28 

R8:47 

83 

28a 

84 

29 

85 

30 

86 

31 

86  a 

R7 

32 

87 

33 

R7 

88 

R6:3-10 

34 

R7 

89 

34a 

R:1-3 

90 

35 

90a 

36 

91 

37 

92 

38 

93 

39 

94 

40 

95 

R5 

41 

R7 

96 

42 

R7 

97 

43 

H6:5-1 

98 

R35 

3-50 


99 

146 

99a 

R5:71 

147 

R3 

100 

148 

R3 

101 

149 

102 

149a 

R5:5-1 

103 

150 

104 

R6:3-1 

151 

105 

R6 : 3-3 

152 

106 

153 

R5:5-1 

106a 

154 

R5:1-5 

107 

155 

R5:1-5 

108 

156 

109 

157 

-10 

158 

R5:4-1 

111 

159 

112 

160 

R5:1-5 

113 

161 

R5:1-5 

114 

162 

115 

163 

R5:1-5 

116 

164 

R5:1-5 

117 

165 

118 

166 

R7 

119 

167 

R7 

120 

R6 : 3-2 

168 

R7 

121 

169 

R7 

122 

R6:3-8 

170 

123 

171 

R5:4-6 

124 

172 

R5:4-6 

125 

173 

126 

R6:4-2 

174 

127 

R6 : 4-2 

175 

R5:6-1 

128 

176 

R5:6-1 

129 

177 

R5:6-1 

130 

178 

R5:6-1 

130a 

179 

R5:6-1 

131 

R6:4-2 

180 

R5:6-1 

132 

181 

133 

182 

R7 

134 

R5:1-3 

183 

R3 

135 

6 : 2-(> 

184 

136 

185 

137 

186 

R5:6-10 

138 

187 

139 

188 

R3 

140 

R6 

189 

R5:6-1 

141 

R6 

190 

142 

R6 

191 

143 

192 

144 

193 

145 

194 

R5:3-5 

■/> 


m 


BIBLIOGRAPHY:  SIBAS 


Code  Title  or.  Description 

511  DATAPRC  Reports  "3IBAS”,  December  1977 

512  SIBAS,  The  Portable  Data  Base 

513  SIBAS,  A  Portable  and  Cost  Effective  CODASYL  Database 
Management  Systeni  (DBMS)  by  Mr,  Jean—Daniel  Gousenberg  [from 
talk  given  a  CDC  users  meeting ] • 

514  deleted 

515  Letter  from  Johannes  Ombick  of  SRS. 

516  deleted 

517  Discussion  with  Vendor. 


^ ')! 


f/9  5/2 


Ad-A112  91% 

ImcLAfisiriED 


tCASUREMENT  CONCEPT  COUP  ROME  NY 
SURVEY  OF  DATA  BASE  MANAOEMENT  SYSTEMS. (U) 
JAN  02  J  HOOOES 
Ofll»005 


DABTS»-81«€-01%7 

NL 


SOURCE  CITATIONS:  SIBAS 


ENTRY 

REFERENCE 

ENTRY 

REFERENCE 

1 

44 

SI2:3 

2 

45 

3 

46 

SI2;5 

4 

47 

SI2:5 

5 

48 

6 

SI1 

49 

SI2:5 

7 

50 

8 

51 

SI2:5 

9 

52 

,  . 

10 

SI5 

53 

SI2:5 

10a 

SI2:1 

54 

SI2:5 

11 

55 

12 

SI1 

56 

SI3:3 

13 

57 

14 

58 

14a 

59 

14b 

SI3:13 

60 

SI1 

15 

61 

16 

62 

SI3:3 

17 

SI2;9 

63 

SI3:3 

18 

64 

SI3:3 

19 

SI2:9 

65 

20 

SI5 

66 

SI2 

21 

76 

SI3:3 

22 

77 

23 

78 

24 

79 

24a 

79a 

24b 

79b 

25 

80 

SI1 

26 

81 

27 

82 

SI3:3 

28 

83 

28a 

84 

29 

85 

30 

86 

SI3:3 

31 

86  a 

32 

SI2:5 

87 

33 

SI3 

88 

34 

SI3 

89 

34a 

90 

35 

90a 

36 

91 

37 

92 

38 

SI2 

93 

39 

SI2 

94 

40 

95 

SI3:7 

41 

SI7 

96 

42 

97 

SI3:7 

43 

98 

SI3:7 

ENTRY 

REFERENCE 

ENTRY 

REFERENCE 

99 

146 

si3;8 

99a 

147 

SI3:8 

100 

148 

101 

149 

102 

149a 

103 

150 

104 

SI3:5 

151 

105 

152 

106 

153 

106a 

154 

SI2;9 

107 

155 

SI2:9 

108 

SI2:8 

156 

109 

SI2:8 

157 

110 

SI3:9 

158 

111 

SI3:9 

159 

112 

SI2:7 

160 

SI2:9 

113 

161 

114 

162 

115 

163 

116 

164 

117 

165 

118 

166 

119 

167 

120 

168 

121 

169 

122 

170 

SI3:16 

123 

171 

124 

172 

125 

173 

126 

SI3 

174 

127 

SI3 

175 

SI1 

128 

176 

129 

177 

SI1 

130 

178 

SI1 

130a 

179 

131 

180 

132 

181 

SI2:9 

133 

182 

13*» 

183 

135 

184 

136 

185 

137 

186 

138 

187 

139 

SI1 

188 

140 

189 

141 

190 

142 

191 

143 

192 

144 

193 

145 

194 

3-52 


SOURCE  CITATIONS:  SySTEM-2000 


ENTRY 

REFERENCE 

ENTRY 

REFERENCE 

ENTRY 

REFERENCE 

ENTRY 

REFERENCE 

1 

44 

99 

146 

SY4:14 

2 

45 

99a 

SY2:5 

147 

SY4:14 

3 

46 

SY3 

100 

148 

4 

47 

SY3 

101 

149 

5 

48 

102 

149a 

6 

49 

SY3 

103 

150 

7 

50 

104 

SY4:1 

151 

8 

51 

105 

152 

9 

SY2 

52 

106 

153 

SY4:18 

10 

53 

SY3 

106a 

154 

SY2 

10a 

54 

107 

155 

SY2 

11 

55 

SY3 

108 

156 

12 

SY4:22 

56 

109 

157 

13 

57 

SY2:2 

110 

158 

14 

SY3 

58 

SY2:2 

111 

159 

14a 

SY4:28 

59 

SY4;12 

112 

160 

14b 

60 

113 

161 

15 

61 

114 

162 

16 

SY4 

62 

SY4:12 

115 

163 

17 

SY1 

63 

SY4:12 

116 

164 

18 

SY4:4 

64 

SY4;12 

117 

165 

19 

SY4:4 

65 

118 

166 

SY2:4 

20 

SY4:1 

66 

119 

167 

SY2:4 

21 

76 

SY4:8,10 

120 

168 

SY2:4 

22 

SY7 

77 

121 

169 

SY2:4 

23 

SY7 

78 

SY4:8 

122 

170 

24 

79 

SY4;8 

123 

171 
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INTERVIEWS:  ADABAS-M 


California 

Computer:  PDF  11/70  (RSX  11/M+) 

The  company  obtained  ADABAS-M  because  of  an  evaluation  by  two  consultants 
and  the  company's  in-house  staff.  Benchmark  testing  compared  ADABAS-M  and 
DRS  (finalists)  after  an  initial  two  level  evaluation  of  15  DBMSs  for  PDP 
computers. 

ADABAS-M  was  chosen  because  of  its  flexibility,  reliability  and  large  data 
base  capacity. 

The  system  is  doing  what  the  vendor  said  it  would  do.  They  are  pleased 
with  the  response  time.  It  does  lack  an  unload  data  base  capability  and  an 
interruptable  load  capability. 

It  needs  to  be  more  forgiving.  The  ADABAS-M  system  seems  to  say  "I  can't 
go  any  further,  you  can  guess  why."  Because  of  this  there  is  an  excessive 
need  to  call  the  vendor  to  read  dumps.  The  vendor  responds  well  when 
called. 

They  were  one  of  the  first  users  of  ADABAS-M  in  the  U.S. ,  but  still  are 
not  completely  aware  of  how  to  use  the  system  effectively, 

ADASCRIPT-M,  the  query  tool  is  insufficent,  also  it  is  rudimentary.  The 
company,  however,  has  little  need  for  a  vendor  supplied  query  function. 

The  data  dictionary  is  very  good.  It  permits  access  of  anything  in 
interactive  mode  only. 

A  data  base  reload  is  needed  when  an  element  is  added  to  the  data  base 
definition. 
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Computer:  VAX  11/780 


ADABAS-M  has  been  in  house  since  about  last  September.  It  was  chosen 
because  a  ”no  pointer"  system  was  desired.  (A  member  of  the  staff  had  used 
ADABAS  on  an  IBM  computer.)  The  system  was  evaluated  against  SEED 
(pointer),  DBMS-32  (pointer),  and  ORACLE  (relational).  Two  systems  were 
rejected  for  being  pointer  systems  and  ORACLE  was  rejected  because  it  was 
too  slow. 

The  compatibility  mode  implementation  limits  VAX  functionality. 
Documentation  is  limited. 

The  users  group  is  effective  and  communicates  information  well. 

The  ADABAS-M  implementation  is  incompatible  with  the  company’s 
time-sharing  billing  process.  <It  is  not  clear  whether  this  is  an  ADABAS-M 
or  a  company  problem. > 

A  report  writer  will  be  available  shortly. 

The  data  directory  schema  works.  It  is  flexible  as  to  modification  and 
user  views. 

The  systo'i*';,  :jtr'  d  <»f  re  arch,  i  ipid  ro.-^I-wP  -nd  '  ility  to 

function  properly. 

Weaknesses  include  lack  of  documentation.  For  example,  there  are  no  hints 
of  how  to  tune  or  optimize  the  system. 

The  system  is  user  friendly  when  the  added  optional  feature  NATURAL  is 
obtained.  The  user  was  able  to  write  a  program  in  ^5  minutes  with  NATURAL 
that  would  have  6  to  8  hours  in  COBOL.  This  was  without  prior  exposure  to 
NATURAL. 

Software  AG’s  other  query  language,  ADASCRIPT-M,  is  useless. 


Virginia  (DC  Area) 

Computer:  VAX 

ADABAS-M  was  Installed  during  November  1981. 

It  was  chosen  because  of  its  large  capacity. 

It  was  chosen  after  comparison  with  TOTAL,  System  2000,  IMS  and  others. 

They  have  over  2000  files  which  are  much  greater  than  the  ADABAS-M  system 
limit.  They  were  able  trick  the  DBMS  into  accepting  the  large  number  of 
files. 

There  is  no  query  capability. 

The  data  dictionary  is  useful.  It  is  on  a  par  with  others. 

Changing  the  data  structure  is  difficult  because  of  the  number  of  files. 

A  major  weakness  is  the  use  of  PDF  architecture  rather  than  the  VAX 
ohitecture.  For  example,  the  PDF  Instructions  and  paging  are  used  in 
rlementatlon. 


INTERVIEWS:  BASIS 


Ohio 

Computer:  Cyber  (Control  Data  Corportation) 

BASIS  was  chosen  by  the  company  because  of  its  portability  and  its  ability 
to  process  textual  data.  The  company  has  used  BASIS  on  a  time  sharing 
computer  since  January  I98I.  They  are  in  the  process  of  obtaining  a 
license  for  BASIS  for  their  own  computer. 

BASIS  was  compared  with  DBMS  170  (for  CDC  computers)  and  System  2000. 
BASIS  was  found  to  require  significantly  less  computer  resources  than  the 
other  systems. 

When  compared  to  System  2000,  BASIS  was  found  to  be  harder  to  use  from  the 
system  side,  but  much  easer  from  the  user  side.  The  company  felt  it  better 
to  train  a  DBA  for  BASIS  than  to  be  continually  teaching  new  System  2000 
users  how  to  query  the  system. 

BASIS  is  a  good  DBMS.  It  has  better  textual  features  than  either  INQUIRE 
or  ORBIT.  BASIS  uses  an  inverted  structure.  It  only  uses  space  for  the 
number  of  repeating  groups  which  are  used.  System  2000  reserves  space  for 
all  groups  even  when  only  one  group  has  data.  BASIS  has  only  a  few  levels 
of  hirearchy  while  System  2000  has  32  levels. 

They  do  not  use  the  data  directory  capability.  The  user  stated  that  the 
System-2000  DESCRIBE  may  be  a  similar  function.  The  user  stated  that  BASIS 
has  a  similar  capability. 

The  strength  of  the  BASIS  system  was  that  it  was  friendly  to  the  users. 

The  weakness  being  the  added  effort  to  bring  the  system  up  and  the 
requirement  for  a  more  highly  trained  DBA. 


3-59 


The  13  term  THESAURUS  is  a  very  useful  feature. 

The  system  has  overall  efficiencies  over  System-2000. 

When  questioned  about  the  use  of  two  DBMSs ,  the  user  stated  that  data 
could  be  unloaded  from  System  2000  then  loaded  onto  BASIS  without 
difficulty.  <The  remark  implies  both  systems  have  good  bulk  load  and 
unload  features. > 

The  concluding  remark  was  that  BASIS  did  all  that  was  asked  and,  then  some. 


Ontario 

Computer;  VAX  11-780 

The  DBMS  is  used  for  a  textual  search  application.  Their  needs  are  for 
Reference,  Citation,  and  New  Article. 

The  system  was  easy  to  bring  up  (less  than  an  hour).  But  BASIS  was  not  new 
to  them. 

OLIVE  (the  on-line  editor)  and  FORMS  are  used  for  entry  of  information. 

The  data  is  saved  along  with  a  relationship  index  for  later  searches.  It 
is  stored  in  a  mother-daughter  relationship.  An  example  of  the 
mother-daughter  relationship  is;  a  conference  is  the  mother  item  and  the 
articles  are  the  daughter  items  <hierarchclal  structure>. 

More  than  100  fields  are  indexed  within  the  data  bise. 

The  security  is  good  but  the  company  has  added  extra  features. 

BASIS  was  benchmarked  against  INQUIRE  <for  IBM  computers>.  BASIS  won 
because  of  better  performance,  flexibility  and  portability. 
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The  stored  query  capability  is  good. 

The  strength  of  the  system  is  in  Its  comprehensive  ability  to  manipulate 
aata. 

BASIS  is  weak  in  the  organization  of  documentation.  Another  weak..cs::  is 
that  OLIVE  does  not  contain  a  full  screen  editor. 


INTERVIEWS:  IDM-500 


California 
Britton-Lee  IDM-500 

The  company  is  building  a  channel  interface,  block  multiplexor  to  link  the 
IDM-500  to  the  UNIVAC  Series  1100  computer. 

They  are  the  largest  independent  supplier  of  equipment  compatible  with 
UNIVAC  computers. 

They  are  developing  the  software  to  permit  ASCII/FORTRAN  interface  between 
the  IDM-500  and  the  UNIVAC  computers.  The  software  will  allow  queries  in 
an  ad-hoc  manner. 

The  data  base  software  will  be  fully  relational.  The  software  will  use  the 
Britton-Lee  IDL  language. 

The  company  expects  to  make  first  deliveries  during  April  or  May  1982.  No 
pricing  information  was  available  at  that  time. 


California 

Computer:  Britton-Lee  IDM-500 

The  company  is  connecting  an  IDM-500  to  the  UNIVAC  Series  1100  computer. 
It  transfers  data  in  byte  or  word  parallel. 

It  uses  an  intelligent  terminal  and  ISI  3803  channel  adapter. 

Software  will  be  provided;  Initially  consisting  of  imbedded  CALLs  to 
Britton-Lee *3  IDL.  This  will  be  followed  by  a  DML  and  SQL  compiler 
capability. 

The  system  will  be  plug  compatible  by  use  of  a  GPI6  (IEEE-^88)  parallel 
interface. 
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The  company  representative  states  that  delivery  will  be  six  months  after 
receipt  of  the  order. 

The  quoted  price  is  $226,000.  It  includes  the  basic  IDM-500  with  three  200 
megabyte  disk  drives,  all  software  and  software  licences.  The  data  base 
accelerator  is  not  included  in  this  package.  Maintenance  on  the  above 
package  is  $2183  per  month. 

He  suggested  that  the  Britton-Lee  one-  week  classes  in  both  hardware  and 
software  are  useful. 


INTERVIEWS:  DMS-llOO 


Washington  DC 

Computer:  UNIVAC  1100  Series 

Two  DMS-1100  users  were  interviewed,  both  of  which  were  also  System  2000 
users.  Both  state  that: 

o  System  2000  is  much  easier  to  use  and  that  it  is 
preferred  when  either  System  2000  and  DMS-1100  can 
be  used  in  Implementing  a  new  function. 

0  Several  capabiliities  are  not  available  on  System 
2000.  When  a  new  function  needs  one  of  these 
capabilities  DMS-1100  must  be  used. 

o  These  capabilities  include: 

-  Multi-user  interaction  with  the  DBMS. 

-  Complex  data  structures. 

-  Network  structures. 

-  A  sub-schema  which  differs  from  the  schema. 

-  Large  or  complex  problems. 

o  There  was  no  mention  of  capabilities  in  System  2000 
which  do  not  exist  in  DMS-1100. 


INTERVIEWS:  SQL/DS 


New  York 

Computer:  IBM  433DC  series 

Because  It  is  In  final  development,  there  are  no  normal  users  of  SQL/DS. 
Some  number  of  beta  test  sites  are  using  pre-release  versions.  Because  of 
agreements  with  these  pre— release  users  the  company  Is  unable  to  disclose 
their  Identities. 
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INTERVIEWS:  RAPPORT 


London,  United  Kingdom 
Computer:  Honeywell  66/60 

The  company  has  used  both  IDS  and  RAPPORT.  They  have  used  RAPPORT  for 
over  two  years. 

It  was  chosen  because  it  was  the  only  Relational  Data  Base  Management 
System  for  Honeywell  computers.  Also  because  RAPPORT  contained 
similarities  with  IDS. 

RAPPORT  is  like  IDS  in  language  style  and  in  the  capability  to  navigate 
from  relation  to  relation.  <  His  statement  not  Mc2's.> 

RAPPORT  met  their  expectations  within  limits.  It  was  a  good 
implementation. 

The  DBMS  was  fairly  easy  to  learn. 

It  became  easy  to  use  after  they  got  used  to  it. 

The  query  works.  One  of  their  systems  is  written  entirely  in  IQL.  <No  host 
language> 

The  data  dictionary  capability  is  limited.  For  example,  there  is  no 
'working  storage'  description.  The  user  must  do  his  own  packing  and 
unpacking  of  data  elements. 

Because  of  the  existence  of  a  utility  program,  modification  of  the  data 
structure  is  not  too  difficult. 

The  system  security  feature  is  not  used  because  the  company’s  needs  are 
met  by  the  Honeywell  file  controls. 

They  consider  RAPPORT  reliable.  Only  one  bug  has  been  found  in  two  years. 
The  OR  operation  has  not  yet  been  not  implemented.  It  is  planned  for  the 


y 
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next  release 


Because  of  the  operation  of  Honeywell  time-sharing,  there  Is  no  way  to  run 
HAPPORT  In  the  multi-user  environment.  COBOL  cannot  be  used  because  It 
requires  the  multi-user  time  shared  environment. 


Wallsend,  United  Kingdom  «  • 

Computer:  ICL  1904 

RAPPORT  was  chosen  because  It  was  the  only  Relational  Data  Base  Management 
System  available.  It  was  Installed  two  and  one-half  years  ago. 

The  programmers  had  little  difficulty  in  learning  how  to  use  RAPPORT. 

The  query  did  not  work  with  release  1.01.  It  should  be  available  in 
release  1.02.  It  will  be  used  in  the  future, 

HELP  is  a  good  feature.  It  permits  listing  of  valid  options  and  valid 
fields. 

The  person  in  charge  of  the  data  base  structure  was  able  to  change  the 
size  of  a  relation  without  the  users  knowing  that  the  change  was  made. 

They  have  no  need  to  use  the  security  controls  or  constraints. 

Multiple  ship  designs  require  the  use  of  multiple  data  bases. 

The  system  is  considered  to  be  user  friendly. 

It  is  simple,  powerful  and  supports  relational  analysis. 

There  are  no  major  weaknesses,  but  there  are  several  small  ones.  For 
example  the  preprocessor  is  slow.  Logica  is  aware  of  this  problem  and  is 
rewriting  the  pre-prosessor. 

(The  user  has  sufficient  confidence  in  the  vendor  promise,  that  he  is  sure 
the  new  pre-processor  ^ will  be  .available  in  the  near  future  and  will  be 
much  better  than  the  existing  one.) 
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United  Kingdom 

Computer:  UNIVAC  Series  1100/21 

The  user’s  reasons  for  obtaining  RAPPORT  were  that  RAPPORT  could  be 
implemented  in  small  parts  while  DMS~1100  must  be  implemented  as  a  total 
unit,  causing  great  impact  upon  their  staff.  In  addition,  the  relational 
structure  was  of  value  because  of  the  necessity  for  frequent  changes  to 
the  data  structure. 

RAPPORT  has  been  in  use  almost  2  years. 

The  user  stated  that  it  met  expectations  with  one  major  exception:  The 
multi-user  capability  did  not  work  because  of  a  glitch  in  UNIVAC *s  "commom 
bank".  This  problem  has  been  by-passed  by  the  implementation  of  a  routine 
obtained  from  another  user.  They  felt  that  if  they  better  understood  the 
system  they  could  have  fixed  it  themselves. 

The  system  was  easy  to  learn  and  to  use.  (It  obviously  is  easy  to  use  on  a 
casual  basis  but,  like  all  complex  tools,  it  requires  significant 
expertise  to  work  around  system  problems  and  to  perform  very  complex 
functions. ) 

The  query  feature  is  good  but  has  limits. 

Modification  of  the  data  structure  is  fairly  simple.  FORTRAN  or  utilities 
are  used  for  this  purpose. 

The  company  has  no  need  for  security  controls  and  did  not  obtain  the 
security  portion  of  RAPPORT. 

The  JCL  is  useful  and  simple  relative  to  the  IBM  JCL. 

Strong  features  are  ease  of  accessing  and  correcting  data  and  the  ability 
to  write  common  sequences  (stored  queries). 


INTERVIEWS:  SIBAS 


Numerous  attempts,  including  consultation  with  the  vendor 
unsuccessful  in  identifying  users  of  SIBAS. 


were 


I  r; 
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INTERVIEWS;  SYSTEM  2000 


Maryland 

Computer:  UNIVAC  1100 


The  company  has  both  System  2000  and  DMS-1100. 

System  2000  is  easier  to  use  and  is  prefered  when  either  System  2000  or 
DMS-1100  will  perform  a  newly  needed  function. 

In  most  cases  System  2000  is  used  for  small  simple  applications,  while 
DMS-1100  Is  used  for  long  applications  or  applications  which  require 
network  structures. 

There  is  no  multi-thread  capability  in  UNIVAC  System  2000,  but  is  expected 
soon. 

System  2000  uses  ’strings*.  The  strings  are  stored  queries  which  are 
loaded  via  key  words. 

The  System  2000  structure  can  easily  be  changed  when  no  "key"  values 
require  change. 

System  2000  was  obtained  about  three  years  ago.  The  respondent  does  not 
know  the  reasons  for  choosing  System  2000. 


Virginia 

Computer:  UNIVAC  Series  1100 


"System  2000  is  different,  but  not  necessarily  better." 

It  is  easy  to  use,  easier  than  most. 

Update  capability  is  not  important  to  the  user. 

System  2000  retrieval  capabilities  are  good. 

The  user  cannot  be  Ignorant  of  data  processing  procedures,  but  any  person 
who  understands  the  use  of  files  and  high  level  langueiges  such  as  *  Report 
Writer*  should  be  able  to  use  System  2000  with  about  a  half-day  training. 

Because  of  the  security  requirements  there  is  no  interactive  use  of  System 
2000  at  the  computer  site. 

The  System  2000  security  package  has  been  locally  enhanced. 


Washington,  DC 
Computer:  UNIVAC  1100 


The  organization  uses  System  2000  release  2.90  with  some  features  of 
release  2.92.  Release  2.95  will  be  implemented  soon. 

The  system  is  very  stable  to  the  user.  Some  bugs  do  exist,  but  these  bugs 
can  be  worked  around. 

They  also  have  DMS-1100.  System  2000  is  easier  to  use  than  DMS-1100. 

The  multi-user,  multi- thread  version  was  part  of  release  2.80  of  the 
UNIVAC  version  of  System  2000.  This  feature  has  been  withdrawn  from  use. 
It  will  be  reimplemented  shortly. 

System  2000  documentation  is  relatively  good. 

System  2000  is  easier  to  use  than  is  DMS-1100. 

System  2000  has  no  networking  capability.  (The  vendor  literature  discusses 
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*Qynamic’  networking  under  user  control). 

System  2000  has  no  sub-schema  feature, 

DMS-1100  is  used  for  problems  which  require  network  structures  or 
multi-user  accessibility.  System  2000  is  used  when  there  is  no  need  for 
multi-user  capability  and  when  a  hierarchical  structure  is  sufficient  to 
solve  the  problem. 

System  2000  was  obtained  during  the  1972-197^  period. 

The  respondent  was  not  Involved  in  the  decision  to  obtain  System  2000. 

(Query  by  Example)  is  a  new  product  which  has  been  used  very  little. 

QUEST  has  a  good  natural  language  query  capability. 

System  2000  does  not  have  a  test  mode. 

They  do  not  have  a  Data  Dictionary  at  the  site.  They  do  not  believe  it  to 
be  useful. 

System  2000  is  used  for  a  central  data  base  and  ten  regional  data  bases 
(all  at  the  central  site).  A  typical  function  is  to  track  money  by  area 
for  various  activities  such  as  "section  8", 

The  regional  data  bases  can  be  accessed  by  area. 
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INTERVIEWS:  MRDS 


D.C.  Area 

Computer :  Honeyvel 1  68/80 


The  system  works  well  with  a  small  data  base.  With  a  large  data  base  the 
system  Is  slow  because  of  excessive  page  swapping. 

The  Logical  Inquiry  and  Update  System  (LINUS)  Is  valuable  to  the 
Infrequent  user,  but  not  worthwhile  to  the  normal  system  user. 

The  major  system  strength  Is  the  flexibility  In  supporting  different 
programming  environments. 

A  weakness  Is  that  general  purpose  computer  systems  (even  ones  as  powerful 
as  MULTICS)  are  not  good  as  word  processors. 

Relational  Data  Base  Management  Systems  should  not  be  Implemented  on 
general  purpose  computers.  In  order  to  work  effectively  they  must  be 
supported  by  special  purpose  function  hardware. 

The  user  stated  that  the  system  Is  very  popular.  It  wa3  Installed  3  years 
ago  with  CPUs.  The  acceptance  of  the  MULTICS  system  (not  necessarily 
MRDS)  has  caused  the  upgrade  to  ten  CPUs.  He  believes  that  the  computer's 
popularity  will  require  the  number  of  CPUs  to  double  in  the  not  distant 
future. 


New  York 

Computer :  Honeywell  6180 
MRDS  can  be  used  at  3  levels: 

0  MRDS  uses  subroutine  calls  from  within  FORTRAN  and  PL/1 


application  programs. 


o  LINUS  is  used  at  terminals  for  user  queries  (and  updates), 

o  M-RPG  is  a  report  writer  which  translates  to  PL/1  code. 

The  organization  has  both  MRDS/LINUS  and  JANUS. 

MRDS/LINUS  is  hard  to  use  relative  to  JANUS.  It  is  awkward  to  set  up 
because  users  must  build  command  strings  prior  to  issuing  queries. 

They  are  not  using  the  most  recent  version  of  MULTICS.  There  are  several 
desirable  features  in  the  next  release  such  as  an  interface  to  Artificial 
Intelligence  Corporation's  INTELLECT  and  an  increase  in  the  maximum 
allowable  number  of  attributes  in  a  file. 

The  user  seldom  uses  MRDS  because  JANUS  is  more  convenient.  He  does  not 
know  of  any  frequent  MRDS  users  at  the  installation. 
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3*2  DBMS  Evaluation 


Following  the  Survey  task,  an  evaluation  was  performed  during  which  the 
the  AMIF  requirements  were  used  as  a  basis  for  determining  the  most 
appropriate  DBMS*  While  during  the  preceding  task  a  general  survey  was 
performed  to  characterize  the  DBMSs,  during  this  task  those 
characteristics  which  apply  to  the  problem  at  hand  are  evaluated  according 
to  a  methodology  based  on  weighting  according  to  importance. 

3-2.1  Evaluation  Methodology 

Selecting  the  candidate  DBMSs  involves  three  major  Steps: 

(1)  Define  desired  DBMS  functions  and  their  relative  importance  to  AMIP 
data  base  management  needs. 

(2)  Rate  each  DBMS  against  the  desired  functions  on  0-10  basis,  with  10 
scoring  highest. 

(3)  Total  the  scores  based  on  the  relative  importance  of  the  function. 
These  three  steps  are  discussed  further  in  the  following  sections. 

3-2. 1.1  Define  FAmatlons 

In  this  step  of  the  methodology,  the  desired  DBMS  functions  are 
identified.  Each  function  is  defined  in  terms  of  sub-functions  and  each 
sub-function,  in  turn,  is  defined  by  its  components.  Relative  weights  of 
Importance  are  assigned  at  the  function  and  sub-function  level.  These 


n 
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welghta  are  based  on  importance  of  the  function  to  AMIP  requirements  and 
are  expressed  in  a  percentage  basis.  At  the  function  level,  the  weighting 
expressed  the  importance  of  the  function  to  the  overall  evaluation. 
Weighting  of  the  sub-functions  expresses  their  importance  to  a  "parent" 
function.  Weighting  stops  at  the  sub-function  level.  A  sub-function’s 
constituent  components  are  not  weighted;  rather,  they  serve  as  a  type  of 
"checklist"  for  the  sub- function.  This  top-down  analysis  of  desired 
functions  provides  a  framework  for  scoring  and  evaluating  the  systems  in  a 
manner  consistent  with  AMIP  application  requirements. 

3. 2. 1.2  DBMS  Ratings 

Each  DBMS  is  rated  on  a  0  to  10  scale  for  each  sub-function  on  its 
capability  to  fulfill  the  components  of  the  sub-function.  This  number  is 
derived  from  a  checklist  formed  from  the  sub-function’s  components,  A 
midpoint  score  of  5  is  given  if  the  system  can  supply  the  capabilities 
defined  in  all  of  the  sub-function’s  components.  Points  are  added  or 
subtracted  from  the  midpoint  score  for  exceeding  or  falling  short  of  the 
requirements.  Although  the  scoring  is  performed  on  a  generally 
subjective  basis,  the  checklist  provides  a  starting  point  for  score 
assignments.  All  of  the  data  used  to  prepare  the  checklist  and  to 
determent  the  subjective  judgments  originate  from  the  footnotes  in  the 
General  Survey  of  DBMSs  (see  Section  3.1 )• 

3.2. 1.3  Total  Scores 

The  scores  for  each  DBMS  are  calculated  in  the  following  manner; 

(1)  For  each  function  do  steps  2  to  U. 

(2)  For  each  sub-function  in  a  function  multiply  the  sub-function’s  score 
by  its  weight.  Save  these  scores. 

(3)  Sum  the  sub-function  scores  determined  in  (2). 
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(^)  Multiply  the  sum  of  (3)  by  the  function's  weight.  Save  these  scores. 


(5)  Sum  the  numbers  from  step  (^)  for  all  functions  to  obtain  the  total 
score  for  the  DBMS. 

3*2. 1.U  Final  Jlvaluatlon  -  A  Caution  Hote 

Total  scores  should  be  viewed  as  guidelines  to  be  used  in  the  evaluation 
and  selection  process,  rather  than  an  absolute  criterion.  Although  the 
final  scores  were  developed  from  a  formal  methodology,  these  numbers  were 
derived  from  subjective  judgments,  not  rigorous  quantitative  measures. 
Where  appropriate,  these  scores  should  be  used  cautiously  and  in 
conjunction  with  other  applicable  selection  criteria  (e.g. ,  system 
maturity,  availability)  to  arrive  at  the  final  selection.  Accordingly, 
the  tabular  presentation  of  "scores",  is  accompanied  by  subjective 
discussion  and  consideration  leading  to  a  final  choice. 

3*2.2  Discussion  o£^valu_tion  Criteria 

3*2.2. 1  Volume  and  Performance  Characteristics 

As  has  been  discussed  in  Section  1,0,  none  of  the  models,  separately  or  in 
combination,  require  data  in  such  volume  as  to  strain  the  capacity  of  any 
of  the  DBMSs  being  evaluated.  Moreover,  except  for  two  possible,  but 
unlikely,  cases  no  foreseeable  expansion  of  the  models^  or  their  use,  will 
approach  the  capacity  of  any  of  the  DBMSs,  The  two  exceptions  are  terrain 
and  weather  aata.  Terrain  and  weather  data  model  requirements  have  been 
calculated  based  upon  current  Army  modeling  procedur-:*.  Currently,  a 
representative  land  area  involved  in  the  modeling  exei  is  600  x  600 

kilometers.  Data  base  volume  requirements  developed  in  Task  1  use  this 
figure.  Terrain  and  weather  data  are  loaded  from  tape  to  on-line  (disk) 
storage,  under  control  of  the  data  management  software,  for  the  area  in 
question.  It  is  felt,  at  this  time,  that  the  only  available  DBMS 
capability  desirable  in  support  of  the  process  is  a  bulk  load  capability 


La  iac!-.itate  loading  of  approt:rlate  data  from  Lape  when  an  exr'* 
beglna.  This  capability  is  deemed  only  "desirable"  in  a  DBMS  rather  than 
"necessary"  because  the  Inplcmentetion  of  software  to  support  these 
specific  bulk  load  operations  wouici  so  a  relatively  minor  effort. 

Another  desiiatie  feature  1 Oi'  support  of  this  application  would  be  DBMS 
control  of  a  tape  libra/’y.  Suen  h  capability  would  provide  user  (or 
program)  access  to  data  resident  on  tapes  in  a  transparent  manner.  With 
such  a  capability  the  user  could  specify  (via  QUERY  selection  criteria) 
which  data  was  desired,  as  is  normally  done  for  disk  resident  data,  under 
control  of  the  DBMS,  In  the  case  of  tape  resident  data,  the  data 
location  control  (e.g.,  Indexes)  would  Indicate  a  reel  number  (or  numbers) 
rather  than  a  disk  address.  The  DBMS  would  automatically  issue  reel  mount 
instructions  to  the  operator  and  proceed  to  search  the  tape  sequentially. 
A  more  sophisicated  version  could  perform  fast-forward  tape  positioning  if 
tape  block  numbers  were  recorded. 

This  capability  does  not  reside  in  any  of  the  DBMSs  surveyed.  To  our 
knowledge,  only  one  DBMS  has  this  capability  -  Data  Manager-1  (DM-1), 
written  in  JOVIAL  on  the  Honeywell  635/6^15  computer  under  the  GCOS 
operating  system  for  the  Air  Force.  DM-1  was  never  commercially  available 
and  has  not  been  used  since  1975* 

Task  1  investigations  at  the  participating  agencies,  including  interviews 
and  analysis  of  Univac  Accounting  System  printouts  containing  system 
resource  utilization  statistics  taken  during  representative  loading 
periods,  have  indicated  that  neither  CPU  nor  I/O  processing  requirements 
arc*  at  tl.e  present  time  approaching  saturation  of  existing  resources.  An 
increase  in  loading  by  a  factor  of  at  least  two  could  be  tolerated  before 
significant  degradation  in  on-line  response  would  be  experienced. 

It  was  decided,  then,  that  data  base  volume  capabilities  of  the  DMBS  was 
not  a  useful  evaluation  criterion  since  it  is  expected  that  all  of  those 
surveyed  can  meet  present  and  future  requirements.  Efficiency  also  is  not 


:u78 


considered  an  overriding  issue  except  in  the  extreme  case  of  a  DBMS  being 
grossly  inefficient.  Interviews  with  users  have  to  date  uncovered  no 
substantial  complaints  regarding  efficiency  and,  Indeed,  one  would  not 
expect  a  product  to  survive  in  the  marketplace  if  there  were  processing 
inefficiencies  of  a  magnitude  great  enough  to  seriously  degrade  the 
application  at  band  (i.e.,  100  <«•  percent). 

3.2. 2.2  Control  and  Standardization 

The  consideration  perceived  as  major  in  the  evaluation  of  DBMSs  for 
support  of  the  Army  Model  Improvement  Program  is  the  issue  of  control  and 
accountability.  This  perception  is  based  upon  the  existence  of  numerous 
sources  of  data,  the  varying  formats  and  subsets  of  the  data  required  by 
the  different  models,  and  the  numerous  versions  of  the  data  required  by 
the  users  of  the  models.  It  is  reinforced  by  the  stated  goal  of  the  Army 
to  implement  a  standard  data  format  so  that  all  users  can  extract  needed 
data  from  a  well  established  repository  having  known  characteristics  (Task 
6  of  the  AMIP  Master  Plan).  Establishment  of  this  standard  format  will 
make  possible  comprehensive  automatic  data  extraction  procedures,  thus 
eliminating  much  of  the  laborious  and  time  consuming  manual  extraction 
currently  necessary.  It  will  also  greatly  lower  the  opportunity  for 
confusion  and  error  inherent  in  a  system  burdened  by  a  multiplicity  of 
formats  and  procedures.  Figure  3-1  shows  control  potential  provided  by  a 
DBMS. 

A  form  of  control  related  to  standardization  of  format  is  standardization 
of  content.  Many  DBMSs  provide  the  capability  for  the  user  to  specify  the 
nature  of  the  data  to  be  entered  into  the  data  base  and  will  reject  data 
not  conforming  to  that  specification.  Thus,  an  element  of  the  data  base 
which  has  been  specified  as  numeric  only  cannot  be  loaded  with  alphabetic 
values.  Further,  a  data  element  which  has  been  specified  as  having  a 
permissable  range  of,  for  example,  0-400  cannot  be  loaded  with  negative 
numbers  or  numbers  greater  than  four  hundred.  Some  DBMSs  provide  the 
capability  to  define  lists  of  acceptable  alpha-numberlc  codes  or  names  and 
will  accept  no  others.  This  capability  promises  to  be  of  great  value  in 
the  AMIP  for  preventing  data  contamination  which  could  result  in  erroneous 
values  being  used  in  the  models  or  in  data  being  unreachable  or  invisible 
to  the  user  due  to  garbling  of  a  crucial  search  key. 
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A  third  aspect  of  control  of  a  data  base  is  the  control  over  who  may 
access  it  for  read  or  update.  This  area,  called  variously  security, 
privacy,  permissions  and  Integrity,  depending  upon  who  Is  discussing  It 
and  what  their  major  interest  Is,  Is  often  confused  In  the  mind  of  the 
evaluator.  To  some  It  means  security  in  the  sense  of  protection  from  a 
concerted  effort  by  unauthorized  personnel  to  gain  information  to  which 
they  have  no  right  or  to  sabotage  the  data  base.  No  DBMS  can  provide  this 
protection  to  a  degree  sufficient  for  military  certification.  Indeed,  no 
computer  system  has  yet  withstood  the  efforts  of  the  DoD  special  team 
whose  job  it  is  to  subvert  military  computer  systems*  security  safeguards. 
The  issue  of  "multi-level  security"  is  an  ongoing  one. 

The  form  of  security  addressed  in  this  evaluation  is  provision  against 
inadvertant  or  casual  unauthorized  access  to  data.  DBMSs  provide  various 
levels  of  unauthorized  access  protection.  Levels  involving  access  to  the 
data  structure  are  most  common  and  are  probably  most  applicable  to  the 
AMIP.  These  include  read  and/or  write  access  permissions  at  the  data 
base,  file,  record  type,  set  type,  and  field  levels.  Less  common  are 
access  controls  based  on  the  data  itself.  Thus,  access  to  a  data  base, 
file,  record  type,  set  type  or  field  may  be  denied  based  upon  the  contents 
of  a  field  or  fields.  This  capability  Is  seen  as  having  less  value  to  the 
AMIP.  It  has  more  application  in  systems  where  total  integration  of  data 
is  necessary  for  high  level  applications,  for  instance  an  executive 
management  information  system  requiring  all  data,  but  where  lower  level 
functions  such  as  payroll  are  used  by  personnel  who  should  be  restricted 
from  access  to  the  salary  information  of  selected  individuals.  This 
element  of  "secrecy"  is  not  present  at  the  modeling  agencies. 

A  final  form  of  control  over  the  data  base  is  that  of  accountability.  To 
maintain  control  over  the  contents  of  the  data  base  it  is  necessary  that 
the  data  base  administrator  have  knowledge  of  originating  sources,  an 
audit  trail  of  data  base  modifications,  and  pointers  to  supporting 
reference  material  where  appropriate.  Two  features  potentially  available 
in  a  DBMS  to  support  these  requirements  are  a  dictionary/directory  and 
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audit  ‘rail  logging;.  |H  our  def  inlta  on,  ''  DbKuSs  oo;.*  r 
dictionary/directory .  A  dictionary/directory  contains  at  least  . 

dei'inlti.  iia  cf  tn  *  data  rase  r.  s  ict  a .3  for  :...:"  aii 

relationships  of  oata,  that  a  ’e  .,ecessary  Information  that  the  DLMl'.  :i.uat 
have  to  manage  the  data.  On  tho  ot^a^r  hand,  a  die tioiiary/dl rectory  can 
contain  informa tiort  auout  t-.ae  data  base  which  goes  beyona  that  requij^ed  by 
the  DBMS  itself  .m.’  i  ;  n  support  of  the  data  bata  administrator 
(information  such  as  source  of  data  or  supplying  agency).  For  a  DdMS 
having  otherwise  superior  capabilities,  but  whose  dictionary/director y  is 
inadequate,  separate  dictionary/directory  packages  should  be  considered  If 
they  can  be  integrated  with  the  DBMS. 

The  discussion  above  presents  the  basic  rationale  for  selection  of 
evaluation  criteria.  In  general ,  the  evaluation  concentrates  on 
functional  capabilities  rather  than  performance  or  efficiency. 

3-2-2. 3  Evaluation  CrlterJlgL  DefjjgJLtlons 

Data  base  management  technology,  being  a  new  and  rapidly  expanding 
science,  is  fraught  with  divers  terms  and  concepts  the  meanings  of  which 
are  often  misunderstood,  understood  differently,  defined  in  conflicting 
contexts,  and  which  are,  in  general,  open  to  discussion.  It  is  necessary, 
therefore,  when  presenting  an  evaluation  keyed  to  these  terms,  to  state 
the  evaluators*  definitions  of  the  terms  and  the  context  in  which  they  are 
used. 

The  definitions  of  evaluation  criteria  are  included  at  the  bottom  of  this 
report  to  promote  understanding  of  the  evaluation. 
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3.2.3 


The  following  pages  present  the  results  of  the  scoring  of  the  DBMSs.  They 
are  arreinged  in  the  following  structure: 

o  Weighting  Assignments 

o  For  each  component: 

*  Component  Answer  page  transcribed  from  the  General  Survey 

*  Component  scores  and  notes 

o  Overall  evaluation  scores,  weighted  and  suummed 
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AMIP  DBMS  Evaluation  Weighting 


EVALUATION 

function 

CATEGORY 

SUB-FUNCTION 

WEIGHT 

1 .0 

USER/APPLICATION  FUNCTIONS 

20> 

1.1 

Update  and  Load 

70J 

1.2 

Query  and  Report 

30? 

2.0 

SYSTEM  CONTROL  FUNCTIONS 

15? 

2.1 

Recovery 

50? 

2.2 

Concurrency  Control 

25? 

2.3 

Security 

25? 

3-0 

ADMINISTRATIVE  FUNCTIONS 

50? 

3.1 

Data  Dictionary 

50? 

3.? 

Validity  Checking 

30? 

3.3 

Reorganization 

10? 

3.^ 

Monitoring 

10? 

4.0 

OTHER 

15? 

4.1 

Documentation  and  Vendor  Aids 

80? 

4.2 

Portability 

20? 

3-8/t 


Component  -  K1 _ Updat_e__a_nd  Load 

Bulk  Relational  Boolean  Host  Language 
DBMS  Load  Operators  Logic  Interface 


ADABAS-M 

Yes 

Yes 

Yes 

Call 

BASIS 

Yes 

No 

No 

Call 

IDM-500 

No 

Yes 

Yes 

Call 

DMS-1100 

No 

No 

No 

DML 

SQL/DS 

Yes 

Yes 

Yes 

DML 

RAPPORT 

Yes 

Yes 

Yes 

DML 

SIBAS 

No 

No 

No 

DML 

S-2000 

Yes 

Yes 

Yes 

DML 

MRDS 

Yes 

Yes 

Yes 

Call 

Scoring  Procedures 

The  elements  of  this  component  are  graded  cbjectivoly:  simpTo  '  ,  ’ 

"No”  answers  for  the  first  three  columns  receive  either  2  points  ur  iione 
The  fourth  column  is  graded  as  follows; 

"No"  =  0,  "Call"  =  2,  "DML"  =  U. 
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UPDATE  AND  LOAD  EVALUATION  SCORES 


DBMS 

Score 

(  1 0  Perf ect ) 

Weighted 

Score  (70J) 

Remarks 

ADABAS-M 

7 

^.9 

1 

BASIS 

2.8 

2 

IDM-500 

6 

4.2 

3 

DMS-1100 

2.8 

4 

SQL/DS 

10 

7-0 

5 

RAPPORT 

10 

7.0 

6 

SIBAS 

2.8 

7 

S-2000 

10 

7.0 

MRDS 

7 

4.9 

8 

1 .  No  Data  Manipulation  Language 

2.  FORTRAN  calls  to  BASLIB  can  be  issued.  On-line  update  requests 
for  oata  set  in  "QUEUE”  file.  Batch  program  later  updates  data 
base.  (Requests  for  Data  cause  search  of  both  data  base  and  "QUEUE" 
file.  Required  fields,  Range  checking,  Table  Look  ups. 

3.  Complete  OEM  implementation  will  have  all  components  Boolean,  DML  and 
relational  operators. 

Existence  of  required  fields. 

5.  COBOL  and  PL/1  only;  no  FORTRAN. 

6.  OR  will  be  added  to  future  version. 

7.  1979  version  SIBINTER  contains  convenient  form  for  calls.  There 
is  no  indicaiton  that  later  version  exists.  Data  Manipulation 
Language  (DML)  exists  for  COBOL;  FORTRAN  (and  others)  use  CALL. 


Built-In  Non  Pro- 

Relational  Boolean  Sorted  Summary  cedural  Report  Stored 
DBMS  Operators  Logic  Results  Functions  Language  Generator  Query 


ADABAS-M 

Yes 

Yes 

No 

Yes 

No 

Limited 

Yes 

BASIS 

Yes 

Yes 

No 

Yes 

Yes 

Yes 

Yes 

IDM-500 

Yes 

Yes 

Yes 

Yes 

Yes 

Implementable 

Yes 

DMS-1100 

Yes 

Yes 

No 

Yes 

No 

Yes 

Yes 

SQL/DS 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

RAPPORT 

Yes 

Limited 

Limited 

No 

Yes 

No 

No 

SIBAS 

No 

No 

No 

No 

No 

No 

No 

S-2000 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

MRDS 

Yes 

Yes 

No 

Yes 

Yes 

Yes 

No 

The  elements  of  this  component  are  somewhat  subjectively  graded  according  to  the 
degree  of  compliance  perceived  by  the  reviewer.  "Relational  Operators",  "Boolean 
Logic",  and  "Stored  Query"  were  seen  as  most  valuable  of  the  set  to  AMIP  and  were 
accordingly  assigned  maximum  point  values  of  2  each.  All  other  elements  were 
assigned  one  point  each.  This,  however,  is  more  in  the  spirit  of  a  guideline  thain  a 
strict  rule. 
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QUERY  AfJD  REPORT  EVALUATION  SCORES 


DBMS 

Score 

( 10  Perfect) 

Weighted 
score  (30%) 

Remarks 

ADABAS-M 

5  ■ 

1.5 

1 

BASIS 

7 

2-1 

IDM-500 

8 

2.J4 

DMS-1100 

7 

2-1 

SQL/DS 

9 

2.7 

RAPPORT 

5 

1 .5 

2 

SIBAS 

0 

0.0 

S-2000 

9 

2.7 

3 

MRDS 

7 

2.1 

1.  Hit  count  and  Histogram  only.  Full  report  generators  for  ADABAS-M 
available  from  other  vendors. 

2.  Results  not  in  sorted  order  can  be  placed  in  temporary  file  then 
sorted.  OR  in  future  version. 

3.  Many  reports  with  single  access  of  data  base. 


{ 


Audit  Save/  Update  Transaction 
DBMS  Log  Restore  Rollback  Rollback 


ADABAS-M 

Yes 

Yes 

No 

No 

BASIS 

See  Remark 

Yes 

N/A 

N/A 

IDM-500 

Yes 

Yes 

Yes 

Yes 

ras-noo 

Yes 

Yes 

Yes 

in  QPL 

SQL/DS 

Yes 

Yes 

Yes 

Yes 

RAPPORT 

Yes 

Yes 

Yes 

Yes 

SIBAS 

Yes 

Yes 

Yes 

See  Remark 

S-2000 

Yes 

Yes 

Yes 

Yes 

MRDS 

No 

No 

No 

No 

Scoring  Procedure 


The  elements  of  this  component  were  graded  equally,  but  some  '.ubjoctive 
judgement  was  called  for  on  the  part  of  the  reviewer  concerning 
completeness  and  or  ease  of  use  of  the  capability  provided. 


RECOVERY  EVALUATION  SCORES 


Sicoro 

Weighted 

DBMS 

(10  Perfect) 

Score  (50J ) 

Remarks 

ADABAS-M 

5 

2.5 

1 

BASIS 

k 

2.0 

2 

IDM-500 

7 

3.5 

DMS-1100 

7 

3.5 

SQL/DS 

9 

'1.5 

RAPPORT 

9 

^1.5 

SIBAS 

7 

3.5 

3 

S-2000 

9 

<1.5 

MRDS 

0 

0 

1 .  Logging  is  to  a  recycling  disk  journal  which  supports  concurrent 
archiving. 

2-  Updates  made  to  "queue*’  file.  Batch  later  performs  update  from 
"queue" . 

3-  Update  made  to  log  file,  Finish  command  causes  transactions  to  be 
copied  to  data  base. 
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Level  of 


DBMS 

Shared 

Access 

Multi- 

User 

Mul ti- 
Threading 

Deadlock 

Provisions 

ADABAS-M 

Record 

Yes 

Yes 

Yes 

BASIS 

N/A 

No 

No 

N/A 

IDM-500 

Relation 

Yes 

Yes 

No  Data 

DMS-nOO 

Area 

Yes 

Yea 

Yes 

SQL/DS 

Record 

Yes 

No  Data 

Yes 

RAPPORT 

Element 

Yes 

No 

Yes 

SIBAS 

Realm 

Yes 

No 

Yes 

S-2000 

File 

Yes 

Yes 

No  Data 

MRDS 

Record 

Yes 

No 

Yes 

Scoring  Procedure 

A  ”Multi-User”  capability  was  considered  the  most  important  element  of 
this  component  and  was  assigned  a  possible  5  out  of  10  points.  Its  score 
was  determined  based  upon  the  depth  ("level")  of  sheired  access  supported, 
deeper  being  better.  Scores  for  "Multi-User"  were  based  upon  the  column 
"Level  of  Shared  Access",  as  follows: 

No  -  0 

File/Relation  =  1 
Set  =  2  (none  found) 

Area/Realm  =  3 
Record  =  4 
Element  =  5 

"Mul ti-Threading"  had  2  points  and  "Deadlock  Provisions"  3  possible 
points.  "Multi-Threading"  would  carry  more  weight  in  an  environment  where 
performance  efficiency  was  critical. 
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CONCURHKNCY  CONTROL  EVALUATION  SCORES 


DBMS 

Score 

( 10  Perfect) 

Weighted 

Score  (25$) 

Remarks 

ADABAS-M 

8 

2.00 

1 

BASIS 

0 

0.00 

2 

IDM-500 

4 

1  .0 

DMS-nOO 

7 

1.75 

SQL/DS 

7 

1.75 

3 

RAPPORT 

8 

2.00 

SIBAS 

6 

1.50 

4 

S-2000 

4 

1 .00 

MRDS 

7 

1.75 

1.  Record  level  lock  with  thme-out  to  prevent  dead-lock.  250  threads 

2.  No  deadlock  provision  needed  because  updates  placed  on  ’^queue"  fil 

3.  IBM  does  not  give  much  information  about  how  software  works. 


L.  Users  may  share  realm,  but  can  lock  records  with  in  the  realm. 


Component  -  2^3 _ gejaarlt^. 


Level  of 

Read 

Write 

DBMS 

Protection 

Permission 

Permission  Password 

ADABAS-M 

Element 

Yes 

Yes 

Yes 

BASIS 

Element 

Yes 

Yes 

Yes 

IDM-500 

View 

Yes 

Yes 

No 

DMS-1100 

Record 

Yes 

Yes 

Yes 

SQL/DS 

Element 

Yes 

Yes 

Yes 

RAPPORT 

Element 

See  Remark 

Yes 

Yes 

SIBAS 

Record 

Yes 

Yes 

No 

S-2000 

Element 

Yes 

Yes 

Yes 

MRDS 

File 

Yes 

Yes 

No 

Scoring  Procedure 

The  elements  of  this  component  were  graded  objectively  on  "Yes/No”  answers 
with  minor  adjustments.  "Read  Permission"  and  "Write  Permission"  were 
graded  according  to  "Level  of  Protection",  deeper  being  better.  "Element" 
Levels  of  Protection  yielded  a  "4"  for  these  two  columns.  "View"  or 
"Record"  Level  of  Protection  yeilded  a  "2".  "File"  Level  of  Protection 
was  graded  at  "1".  Password  capability  was  assigned  a  value  of  "2". 
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SECURITY  EVALUATION  SCORES 


Score 

Weighted 

DBMS 

( 10  Perfect) 

Score  (25$) 

Remarks 

ADABAS-M 

10 

2.50 

1 

BASIS 

10 

2.50 

IDM-500 

5 

1  -25 

2 

DMS-nOO 

6 

1.50 

SQL/DS 

10 

2.50 

RAPPORT 

7 

1.75 

3 

SIBAS 

5 

1.25 

S-2000 

10 

2.50 

MRDS 

2 

0.50 

1.  Password  for  File, 

2.  The  OEM  vendors  should  supply  security  packages  as  part  of  the 
enhancements. 

3.  If  read  access  is  not  available  to  a  field  then  its  value  is  replaced 
with  default  value.  No  error  message  is  given.  Incorrect  results 
possible  when  default  is  used  in  later  calculations. 


Component 


Djita  Dictlopary 


-  ^.1 


DBMS 

Self 

Contal ned 

Schema 

Capa¬ 

bility 

Sub¬ 

schema 

Capability 

User 

View 

Creation 

User 

Query 

Dictionary 

User 

Update 

Dictionary 

ADABAS-M 

Yes 

Yes 

Yes 

No 

No 

No 

BASIS 

Yes 

Yes 

No  Data 

No 

Yes 

No 

IDM-500 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

DMS-1100 

Yes 

Yes 

Yes 

No 

No 

No 

SQL/DS 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

RAPPORT 

Yes 

Yes 

No 

No 

No 

No 

SIBAS 

Yes 

Yes 

Partial 

No 

No 

No 

S-2000 

Yes 

Yes 

No  Bata 

No 

No 

No 

MRDS 

Yes 

Yes 

Yes 

Yes 

No 

No 

Scoring  Procedure 

"Schema  Capability"  carried  the  heaviest  possible  weight  -  "5”.  All 
others  were  scored  "0"  or  "1"  based  on  "Yes"  or  "No".  The  score  for 
"Schema  Capability"  was  assigned  based  on  the  reviewer’s  perception  of  the 
comprehensiveness  and  power  of  the  Schema  Language  (DDL)  provided. 


data  dictionary  evaluation  scores 

ADABAS-M 
BASIS 
IDM-500 
DMS-1100 
SQL/DS 
RAPPORT 
SIBAS 
S-2000 
MRDS 

1.  Users  can  update  their  views  of  the  data  base 
Data  dictionary  is  part  of  nucleus. 


2. 


Componeat 


^.2  Validity  Checking 


Legal  Unique-  Required 


DBMS 

Format 

Range 

List 

ness 

Element 

ADABAS-M 

Yes 

No 

No 

No 

No 

BASIS 

Yes 

No 

Yes 

Yes 

Yes 

IDM-500 

Yes 

No 

No 

Yes 

No 

DMs-noo 

Yes 

Yes 

Yes 

Yes 

No 

SQL/DS 

Yes 

No 

No 

No 

Yes 

RAPPORT 

No 

No 

No 

Yes 

No 

SIBAS 

No 

No 

No 

Yes 

No 

S-2000 

No 

No 

No 

No 

No 

MRDS 

No 

No 

No 

No 

No 

Scoring  Procedure 

The  elements  of  this  component  were  scored  subjectively  according  to  the 
reviewer's  perception  of  their  comprehensiveness.  In  genercil,  the 
elements  increase  in  weight  from  left  to  right. 


3-97 


VALIDITY  CHECKING  EVALUATION  SCORES 


Score 

Weighted 

DBMS 

( 10  Perfect) 

Score  (30$) 

Remarks 

ADABAS-M 

2 

0.6 

BASIS 

7 

2.1 

IDM-500 

5 

1.5 

1 

DMS-1100 

8 

2.4 

SQL/DS 

5 

1.5 

RAPPORT 

5 

1.5 

SIBAS 

5 

1.5 

S-2000 

0 

0.0 

2 

MRDS 

0 

0.0 

3 

U  Table  lookups,  cross  referencing. 

2.  Absence  of  validity  checking  in  documentation  indicates  absence 
of  capability. 

3.  Dangerous  situation  in  MRDS.  Fields  left  blank  on  input  are  filled 
by  following  data,  causing  possibility  of  serious  contamination  of 
data  base 
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Component  -  Reorganization 


DBMS 

Physical 

Logical 

ADABAS-M 

Yes 

No 

BASIS 

No 

No 

IDM-500 

No 

No 

DMS-1100 

Yes 

Yes 

SQL/DS 

Yes 

Yes 

RAPPORT 

Yes 

Yes 

SIBAS 

Yes 

Yes 

S-2000 

Yes 

Yes 

MRDS 

No 

Yes 

Scoring  Procedures 

The  elements  of  this  component  were  graded  objectively  as  follows: 

Physical  =  6  if  present 
Logical  =  4  if  present 

This  allocation  was  based  on  the  assumption  that  frequent  bulk  loading  of 
high  volume  data  (e.g.,  terrain,  climate)  would  require  physical 
reorganization. 


3-99 


REORGANIZATION  EVALUATION  SCORES 


Score 

Weighted 

DBMS 

(10  Perfect) 

Score  (10?) 

ADABAS-M  0 
BASIS  0 
IDM-500  0 
DMS-1100  10 
SQL/DS  1 0 
RAPPORT  10 
SIBAS  1 0 
S-2000  10 
MRDS  ^ 


0.6 
0.0 
0.0 
1.0 
1 .0 
1.0 
1 .0 
1 .0 


NO 

NO 
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Remarks 


DATA  AVAILABLE 
DATA  AVAILABLE 


I  U 


MONITORING  EVALUATION  SCORES 


Score  Weighted 


DBMS 

(10  Perfect) 

score  (lOj) 

Rc:»/j?rks 

ADABAS-M 

6 

0.6 

1 

BASIS 

5 

0.5 

2 

IDM-500 

0 

0.0 

3 

DMS-1100 

7 

0.7 

SQL/DS 

6 

0.6 

RAPPORT 

O.it 

SIBAS 

O.il 

S-2000 

7 

0.7 

5 

MRDS 

5 

0.5 

1.  Report  warns  DBA  of  limits  being  approached.  Thread  and  run 
statistics. 

2.  Command  use  frequencies,  summaries  and  other  averages. 

3.  OEM  vendor  can  implement  reports. 

H .  Many  Reports 

5.  Many  Reports 
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Component  -  >1.1 _ Documentation  and  Vendor  Aids 

Vendor  Vendor 

DBMS  Manuals  Training  Assistance 


ADABAS-M 

DBA  f  Installation, 

Application  Programmer 

Yes 

Yes 

BASIS 

DDL,  Reference,  Utilities 

Programmers,  Thesaurus,  Report 

Yes 

Yes 

IDM-500 

Software  Reference  Manual 

Yes 

Yes 

DMS-1100 

Schema ,  Sub-Schema ,  COBOL  DDL , 

FORTRAN  DDL,  PL/1  DDL,  System  Support, 
Operator,  Summary,  Abstract 

Yes 

Yes 

SQL/DS 

Concepts  and  Facilities 

Yes 

Yes 

RAPPORT 

User,  COBOL  User,  See 

Designing  and  Using  Database, 

Interactive  Query  Language 

Remark 

See  Remark 

SIBAS 

User,  DBA,  Installation 

Yes 

No  Data 

S-2000 

Define  and  Access,  PLEX,  Messages 

and  Codes,  Support,  Report  Writer,  Syntax 

Yes 

Yes 

MRDS 

DBA  Guide,  MRDS  Reference  Manual,  LINUS 
Reference  Manual,  MRPG  Reference  Manual 

Yes 

Yes 

Scoring  Procedure 

The  elements  of  this  component  were  graded  with  equal  weight.  Grades  were 
assigned  subjectively  based  upon  comprehensiveness  of  documentation  and 
clarity  of  presentation,  and  on  degree  of  training  and  assistance 
promised. 
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l;OCUMi-:NTATION  AM)  VENDOR  AIDS  EVALUATION  SCORE:; 


Score  Weighted 


DBMS 

( 10  Perfect) 

Score  (80?) 

Remarks 

ADABAS-M 

7 

5.6 

BASIS 

4 

3.2 

IDM-500 

4 

3.2 

1 

DMS-1100 

8 

t.U 

SQL/DS 

2 

1.6 

2 

RAPPORT 

4 

3.2 

SIBAS 

4 

3.2 

3 

S-2000 

7 

5.6 

4 

MRDS 

7 

5.6 

1.  BRITTON-LEE  offers  classes  in  both  hardware  and  software  for  IDM-500. 
OEM  vendor  may  offer  training  and  assistance. 

2.  Additional  manuals  will  become  available  concurrent  with  (or  before) 
release  of  SQL/DS.  IBM  normally  will  supply  assistance  when  requested. 

3.  No  formal  training  or  assistance  function,  but  the  vendor  assured 
sufficient  training  and  assistance. 

,  Sy3tem-2000  offers  9  classes  on  scheduled  basis  and  3  video  tape 

courses. 
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Component  -  4.2  Portability 


DBMS 

Implementation 

Language 

UNIVAC 

1100 

other 

Computers 

ADABAS-M 

Assembly 

No 

VAX-11,  PDP-11,  IBM 

BASIS 

FORTRAN 

Yes 

IBM,  CDC,  DEC 

IDM-500 

N/A 

Summer  82 

See  Remark 

DMS-1100 

No  Data 

Yes 

UNIVAC  90 

SQL/DS 

No  Data 

No 

IBM  43XX,  30XX 

RAPPORT 

FORTRAN 

Yes 

See  Remark 

SIBAS 

FORTRAN 

Yes 

IBM,  DEC-10,  CDC, 
ND-10,  PRIME 

S-2000 

No  Data 

Yes 

IBM,  CDC 

MRDS 

PL/1 

No 

Honeywell 

SGorlng  Procedure 

The  elements  of  this  component  were  judged  according  to  their  combined  "Portability" 
potential,  with  those  already  available  for  the  UNIVAC  1100  earning  extra  points 
even  if  they  were  not  portable  to  other  machines.  ADABAS-M,  DMS-1100  and  SQL/DS 
lost  points  due  to  a  perceived  reluctance  of  their  vendors  to  transport  them  to 
additional  maniifacturer  machines.  RAPPORT  scored  highest  due  to  the  claim  of 
complete  vendor  support  in  transporting  to  new  machines. 
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PORTABILITY  EVALUATION  SCORES 


Score 

Weighted 

DBMS 

( 1 0  Perfect) 

Score  ( 20J ) 

Remarks 

ADABAS-M 

1 

0,20 

BASIS 

8 

1 .6 

IDM-500 

7 

1.4  1 

DMS-1100 

6 

1.2 

SQL/DS 

1 

0.2 

RAPPORT 

10 

2.0  2 

SABIS 

8 

1.6 

S-2000 

7 

1.4 

MRDS 

2 

0.4 

1 .  Any  computer 

which  supports 

RS-232  or  GPIB  interface.  Two  OEM 

plan  to  deliver  UNIVAC  version  during  summer  of  1982. 

2.  Implemented  on  many  computers.  LOGICA  will  install  RAPPORT  on 
virtually  any  machine  as  part  of  the  license  price. 
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OVER 

ALL 

E  V  A  L 

U  A  T  I 

0  N 

S  C  0  R 

E  S 

ADABAS-M 

BASIS 

IDM-500 

DMS-1100 

SQL/DS 

RAPPORT 

SIBAS 

S-2000 

MRDS 

USER/ APPLICATION 

6.40 

4.90 

6 .60 

4.90 

9.70 

8.50 

2.80 

9.70 

7.00 

Weight  =  205t 

1.28 

0.98 

1.32 

0.98 

1.94 

1.70 

0.56 

1.94 

1.40 

SYSTEM  CONTROL 

7.00 

4.50 

5.75 

6.75 

8.75 

8.25 

6.25 

8.00 

2.50 

Weight  =  15? 

1.05 

0.68 

0.86 

1.01 

1.31 

1.24 

0.94 

1.20 

0.38 

ADMINISTRATIVE 

4.30 

4.10 

5.00 

6.60 

7.10 

4.40 

4.90 

3.70 

4.90 

Weight  =  50? 

2.15 

2.05 

2.50 

3.30 

3.55 

2.20 

2.45 

1 .85 

2.45 

OTHER 

5.80 

4.80 

4.60 

7.60 

1.80 

5.20 

4.80 

7.00 

6.00 

Weight  =  15? 

0.87 

0.72 

0.69 

1.14 

0.27 

0.78 

0.72 

1.05 

0.90 

TOTAL  WEIGHTED  SCORE  5.35 

4.43 

5.37 

6.43 

7.07 

5.92 

4.67 

6.04 

5.13 
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3 .  ? . ^  « 1  Dl3cua.slon  of  Results 

Exam i rial  iori  of  the  Overall  Evaluation  Scores  shows  a  cxear  vic'^c-.-y  for 
SQL/ DS.  Altiiourli  T.ne  dlft'ereace  in  total  score  between  SQL/DS  (7-07;  and 
the  runner-up,  Oho-ViOO  (6.^3)  is  not  dramatic,  other  factors  must  be 
taken  into  consideration  which  In  effect  widen  the  gap.  The  major  factor 
is  that  the  SQL/DS  score  nas  been  significantly  handlcapp-c-d  by  its  poor 
showing  in  the  "OTHER"  category,  which  includes  "Documentation  and  Vendor 
Aids"  and  "Portability".  The  low  score  in  this  category  is  due  to  the 
fact  that  SQL/DS  is  a  newly  released  system  implemented  at  Beta  test  sites 
and  documentation  has  not  yet  caught  up  with  development.  When 
documentation  does  become  available  for  SQL/DS,  there  is  no  reason  to 
assume  that  it  will  be  inferior  to  IBM’s  usual  documentation  quality, 
which  is  excellent.  If  one  were  to  assume  for  the  moment  that  SQL/DS 
could  be  said  to  score  as  high  as  DMS-1100  in  this  category,  it  would 
score  an  overall  7.9^  points. 

The  relational  implementation  of  SQL/DS,  with  its  anticipated  ease-of-use, 
is  another  point  in  its  favor,  making  SQL/DS  even  more  attractive.  If 
there  were  no  other  consideration,  SQL/DS  would  unambiguously  be  the 
winner. 

3 .  ^ ^  * P  Recommendations 

Two  negative  factors  must  be  considered  by  the  Army  before  committing  to 
SQL/DS.  The  first  factor  is  tnat  of  technical  risk,  SQL/DS  is  not  yet  a 
completely  released  product.  Although  the  vendor  claims  a  high  degree  of 
satisfaction  at  the  Beta  test  sites,  one  must  remember  that  it  is  the 
vendor  who  is  talking.  Since,  for  policy  reasons,  we  were  denied  access 
to  the  users  we  have  no  way  of  calibrating  the  vendor’s  statements.  Since 
not  even  IBM  is  immune  to  technical  risk,  the  Army  should  keep  this 
consideration  in  mind. 
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The  second,  obvious  negative  factor  pertaining  to  a  decision  on  SQL/DS  is 
that  of  cost.  SQL/DS  will  not  be  portable  to  UNIVAC  hardware.  The 
adoption  of  this  DBMS  will  include  the  cost  of  replacing  existing  UNIVAC 
hardware  and  existing  application  software.  It  would  seem  that  the 
apparent  benefits  of  SQL/DS  over  DMS-1100,  while  signifioant,  are  not  so 
overwhelming  as  to  justify  Incurring  such  a  cost.  There  may  be  other 
considerations  outside  the  purview  of  this  study,  however,  which  may  be 
moving  the  Army  toward  a  reappraisal  of  hardware.  That  lacking,  we 
recommend  that  the  second  place  DBMS,  DMS~1100  be  adopted  as  the  AMIP 
DBMS.  The  functionality  and  power  of  DMS-1100  are  certainly  more  than 
adequate  for  the  Job  at  hand.  There  are,  however,  nagging  doubts 
concerning  its  ease  of  use.  The  difficulty  of  data  base  design  in  a 
CODASYL  data  model  are  acknowledged.  Two  apparent  manifestations  of  its 
difficulty  have  surfaced  during  this  Investigation.  During  Task  1 
investigations  it  was  discovered  that  an  attempt  had  been  made  to  convert 
a  model  to  DMS-1100  and  was  abandoned.  This  may  be  a  symptom  of 
difficulty  of  use.  In  two  user  interviews  it  was  stated  that  applications 
were  written  for  System  2000  if  at  all  possible.  Only  if  the  Job  could 
not  be  ^one  on  System  2000  would  the  users  resort  to  DMS-1100.  This 
indicates  both  the  difficulty  of  use  of  DMS-1100  and  its  superior  power. 

Before  ending  this  study,  we  feel  that  special  mention  should  be  made  of 
the  IDM-500.  This  device  represents  the  most  advanced  data  base 
management  technology  currently  available  on  the  market.  In  our 
estimation  a  solid  product  has  been  implemented,  which  is  not  always  the 
case  on  the  leading  edge  of  technology.  While  there  are  undoubtly  kinks 
still  in  the  IDM-500,  we  have  been  impressed,  during  our  several  meetings 
with  Britton-Lee  personnel  and  study  of  their  documentation,  with  the 
completeness  of  their  design  and  their  apparent  frankness  concerning 
design  or  implementation  difficulties.  Although  the  Data  Base  Accelerator 


'.j-  I'-jh-liici  'iRHi  i  X  f ,  they  to  cper.  about  dij-ouro' it:: 
Uc-Luy,  wdloh  onu  Lfur  inprcooion  that  ii  ^ty  oir-  reauo:.<or/Iy  c  .>rJ' .  .■•  r.i 
of  Imrninent  success. 

We  feel  that  the  IDM-500  should  be  kept  in  view  for  the  future.  J.o  uain 
attractiveness  is  its  expected  ability  to  increase  data  throughput  :y  at 
least  one  order  of  magnitude  while  at  the  same  time  offloading  much  of  the 
data  management  responsibility  from  the  host  general  purpose  computer. 
While  we  have  stated  that  pe reform a nee  efficiency  is  not  an  important  issue 
to  the  AMIP,  it  may  be  Chat  in  the  future  it  will  be  an  issue  cue  to 
either  the  presence  of  other  applications  on  the  computers  being  used  to 
run  the  models,  or  to  a  future  desire  to  make  the  models  more  rapidly 
interactive. 

Another  potential  significant  benefit  of  the  I  dm -500  is  that  it  can 
support  standardization  and  centralization  of  the  AMIP  data  base,  should 
these  objectives  be  pursued.  With  appropriate  interface  development,  the 
IDM-500  is  eminently  transportable  to  any  host  computer.  Moreover,  should 
the  Army  decide  to  centralize  the  models  data  base,  a  single  IDM-500 
could,  theoretically,  provide  data  base  management  for  all  of  the  model 
computers. 
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EVALUATION  CRITERIA  DEFINITIOMS 


load  large  amouDts  of  data 
by  special  procedures  that  are  faster 
additions. 


from  non-DBMS  files  into  DBMS  files 
than  performing  many  single  record 


RELATIQKAL  OPERATORS  ^  ^  ...... 

Ability  to  qualify  data  records  based  upon  the  contents  of  data  elements 
within  them. 


PgOLEAW  PPEPATORS  ^  ^  ^  , 
Ability  to form  complex  qualification  statements  by  connecting  relational 
operators  with  Booleam  statements  suoh  as  AND  and  OR. 


HOST  LANGUAGE  INTERFACE 

Ability  to  call  the  services  of  the  DBMS  from  a  programming  language. 


AbiJlty^to^retrleve  data  in  an  order  specified  by  the  user. 

BUJI.T-IW  SlfflHARY  FUMCnONS  .  .  .  .  w  a  ^ 

Ability  to  summarize  collections  of  data  by  built-in  functions  such  as 
COUNT,  AVERAGE,  MINIMUM. 

NON- PROCEDURAL  LANGUAGE 

A  l^guage  wbicn  requires  no  looping  or  branching. 

REPORT  GENERATOR 

A  TacTlity for  requesting  printed  reports  in  a  format  specified  by  the 
user. 


STORED  QUERY 

Ability  to  save  a  string  of  query  commands  for  repeated  use. 

AUDIT  LOG 

A  record  of  updates  made  to  the  data  base. 

SAVE/ RESTORE 

Ability  to  aump  the  contents  of  the  data  base  onto  removable  storage  and 
copy  it  back. 

UPDATE  ROLLBACK 

Ab  11  i  ty  to  rest  ore  the  data  base  to  a  state  comensurate  with  the  last 
successful  update. 

.ANSACTION  ROLLBACK 

Ability  to  I'es t ore  the  data  base  to  a  state  commensurate  with  the  last 
successful  transaction  comprised  of  a  user  defined  set  of  updates. 

LEVEL  OF  SHARED  ACCESS  ^  ^  , 

Depth  to  which  multiple  users  can  concurrently  access  the  same  data  (file, 
record,  field,  etc.). 

WLTI-USER 

Abillly Tor  multiple  users  to  access  the  DBMS  concurrently. 


The  overlapping  of  serv.^ce  requests  on  secondary  storage  devices. 

DEADLOCK  PROVISIONS 

Provisions  to  either  avoid  or  correct  a  condition  where  two  routines  each 
have  records  locked  which  the  other  needs  to  access  before  it  can  proceed. 


The^^deptS^to^wSich  access  authorization  can  be  denied  (e.g. , 
element,  etc.). 


file, 


record, 


READ  PERMISSION  ^  ^  ^ 

"Permission  to  read  a  specified  collection  of  data. 
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The  aliility  lo  store  user  provided  definitions  of  data  forrnat  and 
structure  under  control  of  the  DBMS. 

SUH~SCHFMA  CAP/ BALUY. 

The  ability  to  store  subsets  of  schemas  for  specific  applications  of 
users. 

USER  VIEW  CHHATIQN 

Tne  ability  of  users  to  create  their  own  sub-schems. 

USER  QUERY  DICTIONARY 

The  abil i ty  oT  users  to  request  information  concerning  date  base 

cnaracteristics. 

USER  UPDATE  DICTIONARY 

The  ability  of  users  to  create  or  modify  schemas. 

FORMAT  CHECK 

Tneoming  data  is  rejected  if  and  the  user  is  notified  if  it  does  not 
conform  to  the  format  specified  in  the  schema, 

RANGE  CHECK 

incoming  data  is  rejected  and  the  user  is  notified  if  it  does  not  fall 
within  range  limits  specified  in  the  schema, 

hKG_AL  LIST 

Soecified  incoming  data  items  are  rejected  and  the  user  is  notified  if 
their  value  does  not  appear  in  a  list  of  specified  legal  vaues  residing  in 
the  schema, 

UNIQUENESS  CHECK 

^ecTried  incomizig  data  items  are  rejected  and  the  user  is  notified  if 
their  values  are  equal  to  values  of  the  element  already  in  the  data  base, 

PEQUIRED  ELEMENT 

Incoming  records  are  rejected  if  specified  data  items  are  raissing- 
PHYSICAL  REORGANIZATION 

Ability  to  physically  rearrange  data  for  increased  access  efficiency  or 
reduced  storage  requirements  without  affecting  user  programs, 

LOGICAL  REORGANIZATION 

Xbility  to  rearrange  the  logical  connections,  subordinations,  and 
groupings  of  data  without  affecting  user  programs. 

FILE  STATISTICS  MONITORING 

Ability  to  ascertain  and  report  on  the  status  of  the  DBMS  files,  such  as 
number  of  records,  percent  filled,  etc. 

SYSTEM  PERFORMANCE  MONITORING 

Ability  to  ascertain  and  report  on  the  current  status  and/or  performance 
of  the  system,  such  as  number  of  users,  number  of  I/Os,  etc. 

VENDOR„TRAINI_NG 

Tne  existence  of  formal  classroom  training  in  the  use  of  the  DBMS, 

VENDOR  ASSISTANCE 

Access  to  vendor  technical  personnel  for  assistance  with  difficult 
problf.'ras  of  data  base  design  or  use, 

r mpllmntati on  language 

Tne  programming  Tanguage  in  which  the  DBMS  was  Implemented, 


/ 
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